Expose FormGroup component to consumers #71

Activity

1. Tomdango commented on Feb 3, 2021

   

   Tomdango

   on Feb 3, 2021

   Collaborator

   More actions

   The current FormGroup takes a function as it's children, and passes through all relevant props, i.e.

   <FormGroup>
       {({value, onChange) => (
           <Input value={value} onChange={onChange}
       )}
   </FormGroup> 

   If the FormGroup wants to be exposed a bit more naturally, some context would need to be used and implemented in each Input component to ensure that all relevant IDs are also passed along with it.

   In practice, this might look something like:

   const FormGroup = () => {
       const [inputID, setInputID] = useState();
       
       return (
           <FormGroupContext.Provider value={{ setInputID }}>
               <Label htmlFor={inputID}>{label}</Label>
               {children}
           </FormGroupContext.Provider>
       )
   }
   
   const Input = ({ id }) => {
       const { setInputID } = useContext(FormGroupContext);
       
       useEffect(() => {
           setInputID(id);
           return () => setInputID(undefined);
       }, [id])
       
       return <Input id={id} />
   }

   Though I can see this approach breaking down if multiple Inputs are being used inside a single FormGroup, in which case the render function might work better. Both approaches could be used by doing a check on the children prop:

   const isUsingRenderFunction = typeof children === "function";
2. jenbutongit commented on Feb 9, 2021

   

   jenbutongit

   on Feb 9, 2021

   Last edited by jenbutongit

   More actions

   Sorry if I'm missing some context! Instead of render props, I wonder if we do checks on the children instead? The below is a "prescriptive" layout, although you could just {children} if you don't care much for the order.

   //FormGroup.ts
   
   import { Input, Label, Hint, Link } from '~components'
   
   function FormGroup({ hasErrors = false, children }) {
     const childrenArray = React.children.toArray(children);
     const InputChild = childrenArray.find(child => child.type === Input) ?? null; // or typescript guard. You can use child.type === Input if Input is a function 
     const LabelChild = childrenArray.find(child => child.type === Label) ?? null;
     const HintChild = childrenArray.find(child => child.type === Hint) ?? null;
     const LinkChild = childrenArray.find(child => child.type === Link) ?? null;
     return (
       <div className={classNames('nhsuk-form-group', { 'nhsuk-input--error': hasError })}>
         {LabelChild}
         {InputChild}
         {HintChild}
         {LinkChild}
       </div>
     );
   }

   n.b. I forget if you are able to use child.type === Input if Input is an anonymous function (const Input = (..) => { }). It should work if it's defined function Input(..)

   const ExampleForm = ({ children }) => {
     const [firstName, setFirstName] = useState('');
     const [hasErrors, setHasErrors] = useState(false);
     const onFirstNameChange = event => {
       // validation, or whatever else
       setFirstName(event.target.value);
     };
     function onSubmit(e) {
       e.preventDefault();
       // post request
     }
     return (
       <form onSubmit={onSubmit}>
         <FormGroup hasErrors={hasErrors}>
           <Label htmlFor="first-name">{i18n('firstName.title')}</Label>
           <Hint>{i18n('firstName.hint')}</Hint>
           <Input id="first-name" value={firstName} onChange={onFirstNameChange} />
         </FormGroup>
       </form>
     );
   };

   Of course, in ExampleForm you can hoist the id / htmlFor into a variable. id={inputId}. ExampleForm is how is more likely to be used. The logic for validation is most likely going to be at this level, as well as submitting, so it would make sense to define these here, instead of at FormGroup level.

   Using a Context would be overkill for just an id, there's no prop drilling involved really. It would also involve refactoring the input and label to be consumers (adding useContext(..)). Contexts can make testing a pain as well. Providers need to wrap the component under test (whether or not it's shallow or a full render) or it will throw an error
3. Tomdango commented on Feb 10, 2021

   

   Tomdango

   on Feb 10, 2021

   Collaborator

   More actions

   Hey @jenbutongit

   The approach you suggested was actually the original way the forms worked (pre-1.0) - however what we found with it in practice is it's quite restrictive with what you can use inside that element. For example, the following would break:

   <FormGroup>
       <div className="custom-form-wrapper">
           <Input />
       </div>
   </FormGroup>

   The workaround would be to scan all potential child elements of all the children, which ends up being a lot more code and a much more expensive operation on every render than using context.
4. jenbutongit commented on Feb 10, 2021

   

   jenbutongit

   on Feb 10, 2021

   Last edited by jenbutongit

   More actions

   @Tomdango would/is there be a case where you would wrap the input, label, link etc within FromGroup, but not use the FormGroup wrapper + additional classes itself? It's already a wrapping component

   <FormGroup className="custom-form-wrapper"> //outputs nhs-form-group custom-form-wrapper
           <Input />
   </FormGroup>
5. ramyavishnu

   added a commit that references this issue on Feb 18, 2021

   #71 exposing form group component to the consumers, (error, hint, lab…

   ...

   483ae80
6. ramyavishnu

   linked a pull request that will close this issueAdded form group - input, select, text area #82on Feb 22, 2021
7. arupdvsa

   added a commit that references this issue on Apr 30, 2021

   NHSDigital#71 exposing form group component to the consumers, (error,…

   ...

   3895d42
8. colinrotherham commented on Sep 9, 2025

   

   colinrotherham

   on Sep 9, 2025

   Collaborator

   More actions

   Looks like this was added in <SingleInputFormGroup> in the current release

   I've extended it to support components with <fieldset> and <legend> HTML elements in:

   • Upgrade to NHS.UK frontend v10.0.0 and support SSR #267

   This aligns the date input, radios and checkboxes components with NHS.UK frontend

   I've also renamed it to <SingleInputFormGroup> <FormGroup> ready to use
9. colinrotherham

   closed this as completedon Sep 30, 2025
10. colinrotherham

    added this to the v6.0.0 milestone on Oct 1, 2025