Handling different navigation/form progress designs

[afeld]

Hello! I'm at @18F, and part of the team working on the new form for eQIP. We are interested in trying out the Forms System! eQIP is a relatively large+complex React frontend already, so not sure how easy realistic switching over will be from a code perspective...

That being said, I see in the starter app that there are some interface elements included that aren't explicitly part of the specification, namely the progress bar, page numbers, and navigation buttons at the bottom.

In our app, we have a hierarchical navigational structure with conditional styling, etc. To give you an idea:

From an interface perspective, any guesses about how hard it would be to leverage the Forms System? Rather than try to switch the whole form over at once, it would be great to try it out more piecemeal. Perhaps there are lower-level components we can leverage?

I know this is a big question, so feel free to point me to existing documentation/issues. Also more than happy to set up a time to talk through things and see if we can be guinea pigs for the project ([email protected]). Thanks!

[michaelccata]

🙌 thanks @afeld

[dmethvin-gov]

Thanks for the feedback @afeld! Use cases like this are exactly what we need to determine the next steps for this project.

As you've noted, the idea of chapters, pages, and the nav comes from us-forms-system. Some form elements are taken from react-json-schema and others are new widgets in us-forms-system. You can see those in /src/widgets.

At the moment I think the project is too monolithic to be oriented for use cases like this but it seems like we could do it. The formConfig defines everything in one big object (chapters, pages, form appearance, transformation escape hatches, output schema) and it's passed around liberally. However, most widgets have a small number of dependencies, mostly on React or other widgets. Perhaps we could break out the widgets into a different repo that is independent of the nav?

In the meantime you could try pulling out some of the widgets to see whether they work standalone and if they do the trick for your use case. If so, that could make a stronger case for having the widgets separated from the nav and exposed as a project to themselves.

[afeld]

Yeah, a couple ways I could see for using the System more incrementally:

• Try specifying the individual pages as their own forms, so navigating would instantiate a new "form" in the Forms System sense
• Use the underlying widget components directly, as you suggested

Will poke around, but any other guidance is certainly welcome!

[dmethvin-gov]

I was thinking about something similar last night. One data structure could define the chapter/page hierarchy, one could define which widgets go on a particular page and their relation to the output schema, and another map widgets to actual code implementation. For the case of Bring Your Own Navigation you would just want the page definition and widget-to-code setup. Right now we have a single deeply nested formConfig doing all of that and it directly references React components in some cases. With the right encapsulation it should be possible to write a widget implementation in other frameworks or even plain JS but keep the data structures the same.

[annekainicUSDS]

Something @dmethvin-gov and I were talking about on the phone yesterday was imagining splitting the form config up into 2 separate configs:

1. One that is used to specify the questions and the organization of those questions (i.e., everything currently under chapters: { ... })
2. The other that is used to specify top-level information, like the title, Intro component, etc. (i.e., everything outside of chapters: { ... })

Perhaps in this new version of the library where the form config is split, it would be possible to use only the first config, and use your own components for all of the things that wrap the actual questions, like navigation, headers, and footers, etc.

@afeld would that meet the needs of what you're looking for?

[afeld]

That sounds like a good solution!

[jcmeloni-usds]

Just an update here -- as we determine precisely what 2.0.0-alpha might look like (starting Oct 1, aka "phase 2") this is something that will be top of mind It's important for the library to be generic and broadly useful, and not being prescriptive about a lot of things. Right now we're still pretty prescriptive in some cases. That works for some, doesn't work for others. We want to fix that!

[annekainicUSDS]

Duplicate ticket here: #201

[easherma]

#66 also related

[dmethvin-gov]

For now this library is committed to the wizard-style design that provides forward, back, and a review page.