3 ms·

For state management I would start with reading "Thinking in React": https://reactjs.org/docs/thinking-in-react.html https://reactjs.org/docs/thinking-in-react.

For state management I would start with reading "Thinking in React": https://reactjs.org/docs/thinking-in-react.html https://reactjs.org/docs/thinking-in-react.html Step 3 is key. Step 4 is also important. Then try to simplify the app as much as you can. A system has always 2 kind of complexity: the intrinsic complexity and incidental complexity. "Smart engineers" like to show off their intelligence. That usually end up making their life harder by adding a lot of incidental complexity that eventually lead to fragile architecture and frameworks that add more complexity than necessary.

ChrisCinelli 7y ago
When a system has high intrinsic complexity good architecture design is one way to mitigate the problem. The best way that I found so far are the principles of Object Oriented Analysis and OO Design ( https://en.m.wikipedia.org/wiki/Object-oriented_analysis_and_design https://en.m.wikipedia.org/wiki/Object-oriented_analysis_and... ) to break down the system in autonomous subsystems that make sense. Generally the best philosophy is keeping things as simple as possible and refactor as new complexity is necessary.
ChrisCinelli 7y ago
I do not like Redux a lot. It leads to a lot of boilerplate code and a lot of extra files. It also exposes transparently the state that lead by default to a coupling between the "internal" data rappresentation and the rest of the UI components making refactoring a nightmare. Mobx at least leads to a more concise codebase. GraphQL and Relay/Apollo/etc help a lot to reduce the business logic in the front and code to written in general.
- acemarke 7y ago
  As I've mentioned elsewhere in the thread: - Our new Redux Toolkit package (https://redux-toolkit.js.org https://redux-toolkit.js.org) simplifies most common Redux use cases, - Our new Style Guide docs page recommends patterns that result in simpler code, such as using the "ducks" pattern for single-file logic ( https://redux.js.org/style-guide/style-guide#structure-files-as-feature-folders-or-ducks https://redux.js.org/style-guide/style-guide#structure-files... ) - And we're working on a docs rewrite that will update the tutorials to show simpler approaches as well

ChrisCinelli 7y ago

When a system has high intrinsic complexity good architecture design is one way to mitigate the problem. The best way that I found so far are the principles of Object Oriented Analysis and OO Design ( https://en.m.wikipedia.org/wiki/Object-oriented_analysis_and_design https://en.m.wikipedia.org/wiki/Object-oriented_analysis_and... ) to break down the system in autonomous subsystems that make sense. Generally the best philosophy is keeping things as simple as possible and refactor as new complexity is necessary.

ChrisCinelli 7y ago

I do not like Redux a lot. It leads to a lot of boilerplate code and a lot of extra files. It also exposes transparently the state that lead by default to a coupling between the "internal" data rappresentation and the rest of the UI components making refactoring a nightmare. Mobx at least leads to a more concise codebase. GraphQL and Relay/Apollo/etc help a lot to reduce the business logic in the front and code to written in general.

acemarke 7y ago
As I've mentioned elsewhere in the thread: - Our new Redux Toolkit package (https://redux-toolkit.js.org https://redux-toolkit.js.org) simplifies most common Redux use cases, - Our new Style Guide docs page recommends patterns that result in simpler code, such as using the "ducks" pattern for single-file logic ( https://redux.js.org/style-guide/style-guide#structure-files-as-feature-folders-or-ducks https://redux.js.org/style-guide/style-guide#structure-files... ) - And we're working on a docs rewrite that will update the tutorials to show simpler approaches as well