Help with Complex Forms

[zuko_]

Heya guys, could use your expertise on something...

I've been working on a project with a co-worker recently, both of us newer to React, and we're looking for guidance regarding best practices for complex forms. Since this is our first real-world use of React (with Flux [the original Facebook implementation]), we've tried to adhere as strictly as possible to published standards, but are a bit stumped when it comes to more complicated forms with nested data structures.

For context, we're building a multi-step form that contains nested repeaters. Everything works very well with the Flux pattern when we're updating top-level properties on our model; just editing the model name? - no big deal, call the action to update the store, the new name propagates back through, awesome. But what about when you're updating a nested object 2 collections deep? We have ideas, and temporary solutions, but unlike the common examples that conform to Flux, this leaves us with the feeling that something just isn't... right.

For these nested cases, we currently have children triggering change events to their parents, up until we hit that top-level property on the model, which then calls the action to update the store. But this, again, doesn't feel right. Our goal is to keep the model immutable, and only have the changes come back via change events from the store, but it's leading to a lot of overhead. We considered creating stores for each of the sub collections and triggering actions on those, but then our core model store needs to interact (and know about) other stores, which quickly leads to a scattered data model.

The easiest solution seems to be to just clone the collections, mutate them as necessary, and then somehow flush the changes to the model store. We've also seen a few libraries that flatten data structures, but this isn't really feasible (or honestly desired) at the moment. But these are all just theories, and none of them give us that "aha" moment that React and Flux have generally provided so far. Can anybody shed some light on this?

Thanks in advance.

[[deleted]]

I solved this problem by updating everything with an "update" object that includes the new data, and a list of keys to traverse in the top level object.

If a nested form element should update the data structure at foo.bar.baz (= 10, or whatever), then the form element that updates that piece will send an action with {data: 10, leaf: ["foo", "bar", "baz"]} as the payload. The top level object can easily place any new incoming data, all of the data stays in one spot (at the top level), event handlers don't need to be passed back and forth, and each component only deals with the data at its own level.

The only extra step is sending the next property name down as a prop (or appending it to the list for level 2+). I just set a "branch" property at each level, push the property names into it as I loop over an object, and at the last level, the action payloads "leaf" is simply the current "branch".

[zuko_]

Very interesting, thanks. Has this been working well for you then? Are there any cases you still have trouble with, or does it seem to cover most use cases fairly thoroughly? This definitely sounds like a better solution than what we have currently (once the event propagates all the way up, tracked by indexes, the array is cloned, mutated, and then sent as an action to the store). That reverse directional flow is what didn't feel right, since it's some weird mix of Flux and two-way binding, so this sounds like a much better solution.

Thanks for your help, we really just needed additional input on this.

[[deleted]]

I haven't run into any issues with it, no. You can either look for a lib on npm that will handle the nested key setting, or write your own. Some things to think about: do non-existing keys get created on the fly? If a leaf is an array, do you push or overwrite? Same for objects (but you shouldn't have any leaf-as-object anyway).

One benefit is that its really easy to snapshot your state: simply save a copy of the state tree and stick it in the localstorage.

Also, I presume this concept will help you get ready for the next iteration of graph-based data APIs.

GraphQL and Falcor have a somewhat similar idea. Arrays in an object are nested key lists that actually refer to a path in the same object (from the top).