Redux data structuring

Question

I'm trying to build a complex fully-dynamic app with Redux. I mean my App has lots of dynamic-generated forms with generated fields-components on-the-fly. I want to store in my Redux-store visual data about my components too. But how should i do it without mixing real data with visual component data?

For example if i have structure like this

Store { 
  visual: {...deeply nested visual-data-tree...}, 
  data: {...deeply-nested real-data-tree...} 
}

It is hard to render component because i need to search visual data first, then react component "value" in two trees.

But if have a structure similar to this:

Store {
  form {
    visual: {...form visual data...},
    data: {
      //Ok here the form "data" - widgets. Or it must to be visual? :)
      widget1 {
        visual: {type:"ComboBox", opened: true},
        data: 1
      }
    }
  }
}

You see the problem, now i have visual data inside real data of Form widget.

(form - data - widget1 - visual)

Visual data inside the real data is out of the concept.

How do you guys solve same problems of mixing data?

Really sorry for my poor english. I hope i clearly explained the problem.

Janeth

This is currently being discussed in the Redux community - you can track it's progress/discussion here github.com/rackt/redux/issues/159. – Voluble

Thanks for the response, so i'll track it – Janeth

Answer 1

Isn't the distinction superficial? I think a more important rule is that the data in the state should be normalized. For example, if you have Combobox widget letting you choose users, your data shape better be

{
  chosenUserId: 10, // Good!
  users: {
    10: { name: 'Alice' }
}

rather than

{
  chosenUser: { name: 'Alice' }, // Bad!
  users: {
    10: { name: 'Alice' }
}

If the data is duplicated in the state tree, it's hard to update it correctly and avoid inconsistencies.

As long as you keep the data normalized, I see no real need to divide visual and data. You might want to have top-level entity cache that looks like a database (e.g. entities which includes users, posts, or whatever data objects your app uses), but other than that, go with whatever state shape feels most comfortable when retrieving the relevant state.

Bratton

Is there then an easy way how to go back from normalized data to a nested structure when actually rendering the data to DOM? – Toxicity

I would just write “selectors” manually and use them from mapStateToProps of the components. – Bratton

Yeah, that's basically what I am doing right now. I was wondering if this could be automated somehow. For example by implementing something like normalizr.denormalize() which would replace entity IDs by the actual objects (used only right before passing to view for rendering). – Toxicity

@PetrPeller Try googling it, I think a few people tries to do this and somebody’s fork even implemented something similar – Bratton