4 ms·

Are you proposing using the DOM for state management? (of data, not document elements)?

csande17 7y ago
I am proposing that, in many cases, data is trivially representable as document elements. Lots of websites don't actually have much state to store -- at least in terms of the front-end developer's idea of state, of course you often need a database and user sessions and stuff -- beyond what's currently being shown on the page (and occasionally display:none'd, reordered, or scrolled off-screen). "State management" is a problem you think you have only because you're trying to use React for things it isn't good at.
- schwartzworld 7y ago
  Or maybe you just think it isn't a problem because you've never worked on an app that had complex enough state.
deleted 7y ago
[deleted]
Udik 7y ago
Why not storing local state in the components themselves? Why do you need global state management at all, except for the very rare cases in which many totally unrelated components need to tap into the data?
- krzepah 7y ago
  Because some complex application have multitude of variables that need to be passed along various components and that's exactly what is doing redux. In these cases it is much simpler to work with the tools that the community built, and as soon as you actually understand how redux and connect work, you are usually rather happy about what it does for you.
  - Udik 7y ago
    Yes. I think that some applications, with multitudes of variables that need to be shared between unrelated components, will benefit from a store that manages only those variables. For all the other cases, I don't see any reason to use one, and my experience of the same application developed, by different people, with and without a reactive store, tells me that the solutions without a store are generally much simpler and look way more maintainable.
- BubRoss 7y ago
  Many GUI programs use components to store data instead of using them only for display, but this eventually means that your program's state is contained in lots of different data structures with different ways of accessing them. Having everything centralized yet organized enables managing a lot more complexity.
  - Udik 7y ago
    I don't understand, it seems you could say the exact same about object oriented programming in general. But encapsulation is a feature- it allows you to expose to the rest of the application only the data that really needs to be exposed, through a well defined interface. It allows to compose applications of parts that are completely self-contained, without having to think of their interaction with the entire application. I get that in some cases you might need components to plug into a global state that can have multiple sources of change, but this is more an exception than the norm.
    - BubRoss 7y ago
      This might the conventional wisdom, but the reality is that in a single thread, hiding data behind all sorts of obstacles is a huge detriment. If you can already get to it, you might as well be organized so you can get to it easily. 'object oriented programming' (whatever it means exactly) is good for creating interfaces to data. The GUI might need an interface to its data, but the state of whatever is being processed and manipulated is less likely to need a special interface and almost definitely not whatever a component meant to display data provides. If you 'encapsulate' every tiny bit of information inside GUI components you end up with things like storing a string in a GUI label or storing a list in a list selection component. Then every time you want to access that information you have to extract it from the GUI, possibly keeping in mind the lifetime of the UI components.

I am proposing that, in many cases, data is trivially representable as document elements. Lots of websites don't actually have much state to store -- at least in terms of the front-end developer's idea of state, of course you often need a database and user sessions and stuff -- beyond what's currently being shown on the page (and occasionally display:none'd, reordered, or scrolled off-screen). "State management" is a problem you think you have only because you're trying to use React for things it isn't good at.

schwartzworld 7y ago
Or maybe you just think it isn't a problem because you've never worked on an app that had complex enough state.

deleted 7y ago

[deleted]

Udik 7y ago

Why not storing local state in the components themselves? Why do you need global state management at all, except for the very rare cases in which many totally unrelated components need to tap into the data?

krzepah 7y ago
Because some complex application have multitude of variables that need to be passed along various components and that's exactly what is doing redux. In these cases it is much simpler to work with the tools that the community built, and as soon as you actually understand how redux and connect work, you are usually rather happy about what it does for you.
- Udik 7y ago
  Yes. I think that some applications, with multitudes of variables that need to be shared between unrelated components, will benefit from a store that manages only those variables. For all the other cases, I don't see any reason to use one, and my experience of the same application developed, by different people, with and without a reactive store, tells me that the solutions without a store are generally much simpler and look way more maintainable.
BubRoss 7y ago
Many GUI programs use components to store data instead of using them only for display, but this eventually means that your program's state is contained in lots of different data structures with different ways of accessing them. Having everything centralized yet organized enables managing a lot more complexity.
- Udik 7y ago
  I don't understand, it seems you could say the exact same about object oriented programming in general. But encapsulation is a feature- it allows you to expose to the rest of the application only the data that really needs to be exposed, through a well defined interface. It allows to compose applications of parts that are completely self-contained, without having to think of their interaction with the entire application. I get that in some cases you might need components to plug into a global state that can have multiple sources of change, but this is more an exception than the norm.
  - BubRoss 7y ago
    This might the conventional wisdom, but the reality is that in a single thread, hiding data behind all sorts of obstacles is a huge detriment. If you can already get to it, you might as well be organized so you can get to it easily. 'object oriented programming' (whatever it means exactly) is good for creating interfaces to data. The GUI might need an interface to its data, but the state of whatever is being processed and manipulated is less likely to need a special interface and almost definitely not whatever a component meant to display data provides. If you 'encapsulate' every tiny bit of information inside GUI components you end up with things like storing a string in a GUI label or storing a list in a list selection component. Then every time you want to access that information you have to extract it from the GUI, possibly keeping in mind the lifetime of the UI components.