Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
January 25, 2023 09:57 am GMT

State management thoughts...

Every now and then when I'm thinking about managing state in react applications I end up, asking myself the same questions over and over again:

  • Is there missing something or am I just using it wrong?
  • How do I reuse reducer-logic?
  • Is there a way to apply a reducer on the fly to new objects?
  • How do I reflect relationships (1:n) between objects without putting all of them into the same bucket/reducer ending up with crazy, unreadable update logic?
  • How to deal with objects, associated with more than one object (n:m)?

To be more precise let's assume the following data-model:

task-lists tasks comments quick-reactions
threads comments quick-reactions
activities (task-list|task|thread|comment)

A naive approach would end up having three deeply nested objects with a different reducer managing updates each.

The reducers will operate on the data in an immutable way of course, so when I add a task the task-list can properly re-render. With a new comment, a task or thread is able to reflect the changes immediately an so on. So everything is fine here!

Drawbacks:

  1. Update logic ugly as hell: Just adding a quick-reaction to a comment would have to apply updates all the way up to task-lists. breaks readable/maintainable code (to me)
  2. Due to this "update-issue" it's difficult to extract and reuse reducer logic like the quick-reaction, or even the comments-logic at all. breaks DRY
  3. Assuming to have a (totally decoupled) list of activities rendered besides the tasks: It's nearly impossible to for example a change on a task made here, being reflected in the "original" task-list (in a nice way without "hacking" it...). breaks single-source-of-truth

On the other hand: When thinking about having a reducer for every single entity each and somehow managing their relationships by hand this feels very much like reinventing the wheel and implementing a lightweight client-side RDBMS.

Always thinking of a way to somehow apply different reducers to several parts of an object. Combined with the option to just subscribe to specific parts. This would solve 1. + 2. at least...

How do you cope with these problems? Am I missing something? Do I over-complicate things?


Original Link: https://dev.to/metafoo/state-management-thoughts-kbf

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To