The latest articles on Forem by Kjell (@metafoo). https://forem.com/metafoo https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1014379%2F0388d515-b699-47e4-8b4e-eba9b20caf40.jpg https://forem.com/metafoo en Kjell Wed, 25 Jan 2023 09:57:31 +0000 https://forem.com/metafoo/state-management-thoughts-kbf https://forem.com/metafoo/state-management-thoughts-kbf <p>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:</p> <ul> <li>Is there missing something or am I just using it wrong?</li> <li>How do I reuse reducer-logic?</li> <li>Is there a way to apply a reducer on the fly to new objects?</li> <li>How do I manage relationships (1:n) between objects without putting all of them into the same bucket/reducer ending up with crazy, unreadable update logic?</li> <li>How to deal with objects, associated with more than one object (n:m)?</li> </ul> <p>To be more precise let's assume the following data-model:</p> <blockquote> <p>task-lists → tasks → comments → quick-reactions<br> threads → comments → quick-reactions<br> activities → (task-list|task|thread|comment)</p> </blockquote> <p>A naive approach would end up having three deeply nested objects with a different reducer managing updates each.</p> <p>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!</p> <p>Drawbacks:</p> <ol> <li>Update logic is ugly as hell: Just adding a quick-reaction to a comment would lead to apply updates all the way up to task-lists. <strong>→ breaks readable/maintainable code (to me)</strong> </li> <li>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. <strong>→ breaks DRY</strong> </li> <li>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...). <strong>→ breaks single-source-of-truth</strong> </li> </ol> <p>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.</p> <p>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...</p> <p>How do you cope with these problems? Am I missing something? Do I over-complicate things?</p> <p>✌🏻</p> plugin woocommerce software news