TextInput v11 Styles

[SimpleProgrammingAU]

Tasks completed and ready for review

• Adopts v11 styles for TextInput and TextInputSkeleton (TextInput v11 #1888)
• Addresses FluidForm issues relating to TextInput ([FluidForm] TextInput error icon is misplaced #1667)
• Added slots for helperText ([TextInput] helperText enhancements #1633), invalidText, warnText (Standardize props, events, and slots #1621)
• Added elementAttribute objects to replace $$restProps (Standardize props, events, and slots #1621) - is Record<string, string> the correct type for these?
• Property names checked (Inconsistent label property names? #534)

Tasks outstanding

• Padding of Input Element #752: I think this issue might be better resolved in Select - up for discussion
• Input validation issue on TextInput component #941: I couldn't open the REPL links without errors to see the issue
• Tooltip is part of layout calculation #545: I haven't tried to tackle this one yet, will try to address it when I look at the other outstanding tasks above

I also alphabetised the prop list for legibility. I figured this was a good point to submit a PR since all v11 style stuff is done, just need to tidy up the loose ends with the other bugs.

[brunnerh]

I would recommend doing things that cause a lot of non-functional differences, like sorting properties, in separate PRs. That makes it easier to review as there is less noise.

[theetrain]

@brunnerh that's a good tip; I moved this outcome to its own ticket: #1891.

I'll try reviewing this PR as-is for now.

[SimpleProgrammingAU]

I would recommend doing things that cause a lot of non-functional differences, like sorting properties, in separate PRs. That makes it easier to review as there is less noise.

I thought the same thing after the fact. I sorted the properties because I was having so much difficulty finding them in the code as I was reviewing against the React component.

[theetrain]

Thanks for helping standardize some props and events while adopting v11 styles.

Note to self:

TextInput Breaking changes

• on:mouseover, on:mouseenter, and on:mouseleave events are no longer forwarded. Use on:pointerup, on:pointerover, on:pointenter, and on:pointerleave instead
• size no longer supports xl value
• on:input and on:change are forwarded as native events
• values in <TextInput type="number" /> are no longer cast as numbers; they use the default native string type

TextInput new features

• Carbon v11 styles
• New counter and maxCount props to display a character count
• New slots: helperText, invalidText, warnText
• light prop is deprecated. Use the forthcoming Layer componenet instead
• on:input and on:change are forwarded as native events
• New 'pass-through' props: labelAttributes and inputAttributes.

TextInputSkeleton Breaking changes

• on:mouseover, on:mouseenter, and on:mouseleave events are no longer forwarded. Use on:pointerup, on:pointerover, on:pointenter, and on:pointerleave instead

TextInputSkeleton new features

• New 'pass-through' prop: divAttributes

[theetrain]

I think these onChange and parse methods should be removed. We cast
number-type inputs, but the React library doesn't. Maybe this can be handled
in userland, especially since <input type="number" /> when submitted in a
<form> is read server-side as a string.

Demo: https://www.sveltelab.dev/csng8xsyb7bhy56

cc @metonym

[theetrain]

Sorry I submitted my review prematurely. I was using VSCode to review and didn't realize 'request changes' would immediately submit. I'll follow up with the remainder of my review.

[theetrain]

@SimpleProgrammingAU review done; apologies for the repeat reviews - VSCode's review UI is kinda unintuitive.

Last thing to note:

• As discussed in Alphabetize prop names in documentation #1891, please do not reorder the prop names since they're grouped together in a logical fashion.

Over to you!

[SimpleProgrammingAU]

Thanks for the feedback. Back to you :)

[theetrain]

Great work 👍

I updated change notes: #1889 (review)

Changes work well in all themes, and within FluidForm.

I'll leave this open for a few hours in case others want to have a look, then will release.

[gregorw]

Such changes will certainly break existing codebases.

I think we should adopt v11 styles primarily while supporting existing codebases as much as possible.

Once v11 styles are merged to master we can then work towards feature parity with the canonical implementation (React).

V11 styles will be even more delayed if we try to achieve multiple goals at the same time.

[SimpleProgrammingAU]

This is something that will happen eventually anyway. I'd make the case that given we're already making breaking changes, it may as well all come at once.

Most of the fixes to codebases will be relatively trivial (i.e. largely find & replace and copy-paste).

I would add that file-by-file, the changes haven't been onerous from a coding perspective, either.

[gregorw]

I’m glad you’re pushing this project forward. We want the same thing. My worry is that once we open a PR from next/v11-styles → master the reviewer, i.e. @metonym, will have a very hard time assessing all these to some extend unnecessary changes. What I’m saying is that we will have v11 styles on the master branch earlier if we kept the change to a minimum.

This is something that will happen eventually anyway.

We could propose this very change to master then. It’s unrelated to v11 styles. Feature parity with the canonical implementation is a separate issue.

I'd make the case that given we're already making breaking changes, it may as well all come at once.

1. I don’t think we should make breaking changes. At least I tried not to make any unnecessary breaking changes.
2. I don’t think making them all at once is a good idea because it makes reviewing, writing release notes and upgrading apps very hard.

Most of the fixes to codebases will be relatively trivial (i.e. largely find & replace and copy-paste).

Are you running a carbon-components-svelte app in production? We do. If we suddenly miss events on TextInput we cannot just run find & replace. It’ll break the application.

[theetrain]

I appreciate the discussion. I hope I have addressed Gregor's concerns in #1872 (comment) - let's continue there.