How to handle complex form?
Hey everyone,
Exciting news! I'm currently taking on the task of transforming a portion of an existing web app into a Single Page Application (SPA) using Solid 🥳
Our present setup functions more as a proof of concept, with each field triggering a POST request to a server endpoint upon being edited (using the onBlur event), thanks to Remix. This triggers a server-side computation of the project, with the results reflected back to the user through the Remix mechanism.
Moving forward, I envision a shift towards a Solid SPA environment, where all modifications are locally managed. Computation would become an automatic response to any field edits. The only time we'd interact with the server is when saving the project, pushing the accumulated data in its entirety.
However, I've stumbled upon a tricky situation concerning the layout of the form - if we're still considering it a form.
Our data organization has a hierarchical pattern: a project can contain numerous elements, and each element can host multiple layers. To fully compute a project, you need access to the entire hierarchical structure. Nonetheless, each layer has the ability to self-compute, and an element can compute itself based on the intermediate results of its layers, and so on.
I'd appreciate any guidance or references to useful articles or resources that could help me wrap my head around this. What would be the most efficient approach to organizing such a form?
Thanks in advance for your thoughts!
5 Replies
Gotta say that form is insane! Instead of having one big form could you change the setup to be a that of a form wizard or broken up into stages? Because realistically no human being can keep track of so many fields from a visual or mental standpoint. So if it were broken up into steps, similar to how you purchase a plane ticket, perhaps that would ease the complexity of the form and make it more user friendly?
Individually each form must be trying to achieve one core thing I would imagine? And if not group the ones that are most similar or rely on another, and then move to the next stage.
Also if your task is to recreate it, I'd suggest talking to all of the key users of the tool first. Find out what they love/ hate about the old one and see where things need to stay the same or need to be improved. Then you could design a proxy in Figma, get their feedback on it until you get something final.
I'm sure that will make this more approachable/ doable. Because I believe you can do everything without an extra dependencies or libraries outside of Solid itself.
Hi @carlonyte, I fully agree with you, this is madness. But this "form" is for experts in a specific field, and they manage to cope with the amount of information. I tried to convince them to split the view, but they like and (apparently) need this "view all" design
I think I have to work on a simpler (yet complex) version to see how I can split this code-wise.
Ah I gotcha. We’ll yea you gotta give them what they want 🙃
I spent some time looking at it and I just want to be sure. The left side and right side are duplicates intentionally right?
Yes, these are variants from a same project
In order to compare two similar projects with minimum changes
Maybe my modular and type safe form library can help: https://modularforms.dev/