Mental model for the forms implementation
Congratulations! You've reached the end of this tutorial explaining the pattern and thinking behind Lore's approach to forms.
As stated in the beginning, one of the goals for this tutorial was to explain the reasoning and construction pattern behind Lore's approach to forms, so that even if you don't like the interface, you may find some useful ideas to take back to your own applications.
For example, you might think that this pattern takes things too far, and has too much abstraction, and is consequently a bit difficult to understand. And that's totally okay! There is indeed a lot of abstraction.
But the hope is that because the tutorial started with a fully explicit form, and then built up from there, that even if you dislike the final interface, there might still be something in the middle that appeals to you.
The motivation for building this library came from an application that had ~70 API endpoints, and dozens of forms. Managing them became a total nightmare, and a quest began to find not only patterns to simplify their construction, but a higher level pattern that could be used to remove the need to create them at all.
Additionally, whatever approach was settled on also needed to be applicable to any application, regardless of the branding and visual design of the forms themselves. That requirement is why Lore includes two versions of the hooks; one for Bootstrap, and another for Material UI.
The final pattern has worked well in practice, but as it evolved through various iterations, it became clear the abstraction tiers could be problematic. Sometimes this was because it made it hard to remember and reason about how the forms worked, but mostly because it made it hard to use the forms themselves as a starting point for new (highly custom) forms that really broke the patterns established by the blueprints.
In other words, everything worked well until I needed to break out of the blueprints, and there was no easy starting point to do that from.
To make that part of the process easier, there are some CLI commands that can be used to create new forms and dialogs from, that model the appearance and behavior of the ones generated by the hooks.
You can learn more about those commands in the links below, which also show the different types of forms and dialogs that can be created.
If you have any questions, issues, features requests, or ideas to improve the user experience, don't hesitate to submit an issue with your thoughts!
Documentation is challenging to create, due to the diverse perspectives and knowledge of the people reading it. But if you're confused or struggling to understand something, you're probably not alone, so please don't hesitate to file an issue.