> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session.
I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local state (useState)
Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount.
That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types.
I really like this separation of concerns:
- dumb components: to worry just about the looks and local state.
- controllers: to worry about data in, actions out, life cycle and navigation.
- Ducks: Management of data fetching and global state.
I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.
I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local state (useState)
Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount.
That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types.
I really like this separation of concerns:
- dumb components: to worry just about the looks and local state.
- controllers: to worry about data in, actions out, life cycle and navigation.
- Ducks: Management of data fetching and global state.
I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.