Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WNMGDS-2843] Add ds-text-field component #3172

Merged
merged 18 commits into from
Jul 26, 2024
Merged

Conversation

pwolfert
Copy link
Contributor

Summary

WNMGDS-2843

Adds a new ds-text-field web component.

How to test

  1. Try it out in storybook
  2. If you really want to, you can try adding it to the astro example too, but I did that myself already and removed it because I didn't have a good use case for it in the example, but maybe that's lazy and I should actually just revamp the example page and make a more meaningful form example that includes more components.

Checklist

  • Prefixed the PR title with the Jira ticket number as [WNMGDS-####] Title or [NO-TICKET] if this is unticketed work.
  • Selected appropriate Type (only one) label for this PR, if it is a breaking change, label should only be Type: Breaking
  • Selected appropriate Impacts, multiple can be selected.
  • Selected appropriate release milestone

If this is a change to code:

  • Created or updated unit tests to cover any new or modified code
  • If necessary, updated unit-test snapshots (yarn test:unit:update) and browser-test snapshots (yarn test:browser:update)

If this is a change to documentation:

  • Checked for spelling and grammatical errors

@pwolfert pwolfert added Impacts: Core Impacts the core DS primarily, changes may occur in other themes as well. Type: Added Indicates a new feature. labels Jul 25, 2024
@pwolfert pwolfert added this to the 11.0.0-beta.1 milestone Jul 25, 2024
Copy link
Collaborator

@jack-ryan-nava-pbc jack-ryan-nava-pbc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks great! Mostly just some discrepancies I noticed in the Story plus some questions about how some props (well, actually just one prop) are/is being passed in.

},
'error-placement': {
description: 'Location of the error message relative to the field input',
options: [undefined, 'top', 'bottom'],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: If it's undefined the default behavior is to place the location on top, can/should this detail be captured here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By "captured here" do you mean explaining that in the description?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Default position is different for different child design systems.)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep! I do mean explaining that in the description.

Copy link
Collaborator

@kim-cmsds kim-cmsds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, this looks great to me! I left a few non-blocking questions.

Copy link
Collaborator

@zarahzachz zarahzachz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just some small comments you can disregard or accept

expect(input).not.toHaveAttribute('disabled');
});

it('applies additional classes to the wrapper', () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following is probably more philosophical than the scope of this ticket warrants. Feel free to disregard my stream-of-conscious take here:

This test initially confused me because I associate "wrapper" with the host for 🚾, and having a special prop to apply a class to a host is unnecessary because it's HTML and class would work fine.

Anyways... I had to do a double-take and read what the test was actually doing and realized "wrapper" means something different because it's querying the clearfix style in the test, which is the internal div within the host wrapper. Is this div even needed? Who clearfixes in the era of flexbox and grid?

Do we need better language when talking about these sorts of tags?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might very well be able to remove that "wrapper" div now. I agree that it's beyond the scope here, but it's worth considering for the future (@kim-cmsds).

That's a great point about the wording here being confusing. I think I'll change it to "root element" or something like that.

Comment on lines 98 to 104
description:
'Text showing the requirement (ie. "Optional", or "Required").\nIn most cases, this should be used to indicate which fields are optional.\nSee the [form guidelines](https://design.cms.gov/patterns/Forms/forms/) for more info.',
description: (
<>
Text showing the requirement (ie. &quot;Optional&quot;, or &quot;Required&quot;).\nIn most
cases, this should be used to indicate which fields are optional.\nSee the{' '}
<a href="https://design.cms.gov/patterns/Forms/forms/">form guidelines</a> for more info.
</>
),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out this change fixes the doc pages but breaks the story pages (probably an error when rendering the Storybook controls). I think Storybook must not like rendering non-strings in the control descriptions.

This was fine on our docs page with our custom attributes table, but Storybook crashed trying to render these values in story controls. The error was completely unhelpful and the stack trace was all through minified code, so I had to guess and test to find the problem here. Now we know these can only be strings.
Copy link
Collaborator

@jack-ryan-nava-pbc jack-ryan-nava-pbc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@pwolfert pwolfert merged commit a15cb15 into main Jul 26, 2024
1 check passed
@pwolfert pwolfert deleted the pwolfert/ds-text-field branch July 26, 2024 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Impacts: Core Impacts the core DS primarily, changes may occur in other themes as well. Type: Added Indicates a new feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants