# Rage Report: FormBuilder Deluxe
## Goals:
- Discover an easier way to manage multi-forms(accordion pattern) than previously implemented
- Discover an easier way to handle blending split columns with single columns
- Experiement with cache so that we can save the user's progress.
## Experiement Design
Previously, on txBuilder form, my solution to the form/accordion problem was to map many formBuilders, then compile the output into a master formbuilder.
One key design consideration of the old multiform is that it had to compose many independant forms becuase we need to add/remove them at will. In this implementation at least, we know the structure of the form and can therefore structure the form with data.
#### What this needs to do:
- [ ] Take in static data that describes the form, each input, each section of the accordion, each split section of the form.
- [ ] Outputs the data consistently and cleanly through the values object.
- [ ] Exectute the summon TX the same way the existing summon form does
- [ ] Formbuilder or TX API supports lifeCycleMethods (can pass in functions that execute at differing stages of the TXs lifecycle)
- [ ] Maintain consistent spacing and behaviour when composing different section and layouts in the form.
- [ ] Caches the user's data on keystroke so that if they were to close the window and open it back up again, they would see it again.
- [ ] Deletes cache when on a TXsuccess lifeCycleMethod.
## Expected Results:
- Accordion notation will be verbose but easy to implement
- Same with columns
- There will be difficulties around spacing, but it will come together with enough elbow-grease
- Saving to local storage will be easy enough. But it will be challenging for react-hook-form to recognize the cache and auto-populate the form, then pass all that data to formBuilder. If it's too much of a problem, I'll leave it for now and document the challenges so I can come back later and focus on this problem specifically.
## Actual Resutls
- Conforming RadixUI to FormBuilder will be tougher than initially thought.
- Building an accordion formBuilder is veryDifferent and what I thought given the challenges of the design. Here is an example of one of these challenges:

The generated message below has no programmitic way of being generated.
This custom functionality would break the pattern of using static data to build our forms. There are two solutions to this.
- Work with design to somehow create a standardized way of generating this message based on data that is in the form.
- Build a form manually and generate these messages.
Neither are lightweight solutions.
Building with this