New Component: InputGroup

[brandonlenz]

Input Group

USWDS Version

Not sure when it was introduced, but some other components (e.g. Input Prefix and Suffix) make use of this convenience component, and it seems like we should include it as well. It is very similar to FormGroup.

Description

A component that USWDS uses to group components (linked above), but not mentioned as its own exclusive component. Providing this convenience component may be nice

Requirements (proposed)

Should be able to toggle the error state with a prop

Prop Interface

interface InputGroupProps {
  children: React.ReactNode
  className?: string
  error?: boolean
}

Example Implementation (proposed)

export const InputGroup = ({
  children,
  className,
  error,
}: InputGroupProps): React.ReactElement => {
  const classes = classnames(
    'usa-input-group',
    { 'usa-input-group--error': error },
    className
  )

  return (
    <div data-testid="inputGroup" className={classes}>
      {children}
    </div>
  )
}

[jenbutongit]

I think InputGroup would be a good candidate for the API I suggested in here #1687, although it is generally quite restrictive, I'm not sure if that's how you'd like the lib to be consumed.

children would only be of type (Label | Input | InputPrefix | InputSuffix)[] Then you would be able to control the order in which they appear using React.Children.toArray. I think this article touches on it, but you get the idea (hopefully?) https://www.smashingmagazine.com/2021/08/react-children-iteration-methods/. You could have extra controls for prefix/suffix so that you don't have a prefix AND suffix, or throw an error when there's an input without a label etc.

[brandonlenz]

@jenbutongit thanks for that detailed article! That's super helpful. From what I've seen from some internal conversations, we like the API you suggested! I think we just need to have a conversation about how to roll out a change like that.

Right now, we generally lean towards as flexible an API as possible, so that consumers can mix and match components as they choose (for better or for worse 😅). I think that is due in large part so that if they're using their own components or components from another library, they play nicely together. (Plus if they need a component new to USWDS that has not been implemented in React USWDS yet, they'd be able to do that. So that would likely be the main reason to not be highly restrictive when typing children.

When it comes to introducing the API pattern you suggested, I suppose we need to decide if that should be done one component at a time (i.e. new components are built using the "dot" syntax), or if a single breaking release should be targeted to convert all the relevant components to use this syntax.

I have some minor reservations about putting the library in a state where a fraction of the Components use a different API syntax than the rest, but will happily invest some time in ideating with some of the other maintainers about how we'd like to pursue this change 😄