Hosting Dashboard: Add domain glue records add/edit screen

[m1r0]

Part of DOTDASH-202

Proposed Changes

• This change introduces the glue records add/edit form.
• A few things are missing that will be added in the next iteration. Those are tracking, tests, and probably better error handling.

dv9Srg.mov

Why are these changes being made?

• This is part of the Hosting Dashboard: Domains project.

Testing Instructions

• Go to /v2/domains/[domain]/glue-records and click Add glue record.
• You should be redirected to the add screen.
• Test the form validation by adding an invalid server name and IP address.
• Add a valid glue record. You should be redirected back to the listing screen.
• Click on the new record. You should be redirected to the edit screen.
• Update the IP address. You should be redirected to the listing screen again.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-152980

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-152980&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-152980&env=a8c-for-agencies

[m1r0]

It looks like the ValidatedInputControl is still in beta, so I'm not sure if this is the right thing to do.

I'm using this because I found no other component that has a validated input that can have a suffix.

@hambai, I saw that you faced the same issue in #105113. Do you think this is an ok approach for now?

[p-jackson]

Is that what this message was referring to?

If it is something we need for domain input boxes, maybe this is something we could create and contribute upstream 🤔 A place to ask about it might be #atelier-data-views

We could leave the suffix out of the component for now and follow up once we have a done the component work?

[arthur791004]

I don't think we can import it directly...so I didn't use it in #105191

[m1r0]

Thanks, Arthur. I've updated the code to use InputControl while we wait for a better solution.

@mirka, I'm not sure if someone has already contacted you, but do you know if there are plans to release the validated-form-controls package? Our project could use the ValidatedInputControl component.

[mirka]

Thanks for the ping! Those validation components are kind of meant to be a temporary solution, especially now that we're working on a new set of components. Hence the reluctance to make them directly available to consumers.

I also just recently removed them from the wp-calypso repo entirely (#105219), since canonical development has already moved to the Gutenberg repo.

At the moment we're exposing them for external use mainly through the DataForm abstraction in @wordpress/dataviews. Is that an option here?

[m1r0]

Thanks for the quick response, @mirka!

At the moment we're exposing them for external use mainly through the DataForm abstraction in @wordpress/dataviews. Is that an option here?

Our main hurdle is not having the ability to add a suffix to the DataForm fields and also have validation. In our current project, we have a few forms that look something like this:

One option that we found was to use the InputControl component, which has a suffix, but we can't make the validation messages work. ValidatedInputControl does the job, but we can't use that because it's not exposed.

Do you have any suggestions on how to approach this? 🙏 Maybe contribute a solution, e.g., adding a field suffix in Gutenberg?

[mirka]

I see. Not sure how far DataForm wants to support extension points like this in the standard data types (cc @oandregal).

If not feasible to add this feature in DataForm, I'm fine with temporarily exposing any of the validated form components you need as an unlocked API in @automattic/components, similar to what we did with Menu. (In Menu we went through a lot of trouble to manually add back the TS information that gets lost when components are locked through the privateApis mechanism, but I think we can skip that effort for this. At the time, we were expecting to be in a contribution ban for a much longer time.)

[oandregal]

I see. Not sure how far DataForm wants to support extension points like this in the standard data types.

I can see how it'd be beneficial to support this, so consumers can configure the Edit component.

My main concern is that we shouldn't couple DataForm to a specific component implementation. We want to be future-proof, which means that we can update the underlying components when/if require it. I don't think we should allow passing any prop to the underlying components, for example. This needs to be discussed in a case-by-case basis.

@mirka do you think prefix/suffix for inputs is a common enough concept that we can incorporate it to DataForm and be future-proof?

I'm thinking we could do this via the Edit function of a field. It's now a React component or a string (e.g., text, email, integer). It could also be an object with some props to be passed down to the component. For example:

{
  id: 'field',
  Edit: {
    type: 'text',
    suffix: 'suffix-will-go-here'
  }
}

[mirka]

I totally understand how you wouldn't want to couple DataForm to underlying component implementations, so personally I'm not pushing too hard in that direction.

And the validated form components will be available for public use eventually, in one form or another, so in the long run it's not absolutely necessary that DataForm support these customizations in the standard field types.

On the future-proof angle, the prefix/suffix props themselves are pretty stable, and there are no plans to remove them even in the next-gen components. However, there's a subcomponent (InputControlPrefixWrapper) that can be used to control padding in the prefix/suffix slots, and that part is subject to change 😅 Plus those old subcomponents will not work with the next-gen InputControls. So these types of small back compat issues cannot be 100% avoided if we go down this route. If this is the first time this request has come up, it's maybe too early to say that this is a common enough use case.

[p-jackson]

Is that what this message was referring to?

If it is something we need for domain input boxes, maybe this is something we could create and contribute upstream 🤔 A place to ask about it might be #atelier-data-views

We could leave the suffix out of the component for now and follow up once we have a done the component work?

[fushar]

Could we rename domains/overview-glue-records to domains/domain-glue-records, to be consistent with the others?

[p-jackson]

I left some more feedback but after that I think the code is looking good from my point of view.

I think when it comes to that input field which includes the subdomain it would be better to just leave it like Arthur did in the earlier PR. https://app.graphite.dev/github/pr/Automattic/wp-calypso/105213/Hosting-Dashboard-Add-domain-glue-records-add%2Fedit-screen#comment-PRRC_kwDOArzw_86ICrFp

It seems like we should figure it out upstream and then we can bulk-fix-up the Hosting Dashboard input fields that need it.

[m1r0]

Could we rename domains/overview-glue-records to domains/domain-glue-records, to be consistent with the others?

Thanks for the review, @fushar. The folder was renamed. 👍

It seems like we should figure it out upstream and then we can bulk-fix-up the Hosting Dashboard input fields that need it.

@p-jackson Makes sense.

I think I've addressed all the feedback. @p-jackson @arthur791004 @fushar, could you please give it another look? 🙏