- Mostly for CRUD operations.The first problem was to denormalize the entire state (the use of the library “normalizr” is encouraged by redux docs, I didn’t know it when I started and I did it manually) in a way to split it in small pieces, each with a reducer.
- It’s useful and speeds up a lot the development process.DemoSummary of my pros and consProsTest driven development is made easy, thanks to pure functions, and increases the development productivityOnly the root component (I call it container) is connected to the reducer, all the actions and state are passed through props.
- This makes it easy to use component composition and write stateless components.Code linearity, everything is simple and doesn’t differ much from one project to another.Immutability: forcing to keep an immutable state helps a lot avoiding weird bugs.The Log middleware in dev mode, showing all the different states before and after an action is dispatched, is of a great help.ConsIt’s difficult to handle relationships and there isn’t any official library with documentation and support to help you with it.Redundant code, every action is written manually, even the most common, like changing an attribute of the state.Normalizing a complex state with many level of nested objects doesn’t always seem the best approach.My best practicesDirectory structure by module instead of scope.
- A better approach it could be to retrieve the new state from the server when necessary and handle the state relationships on the database layer.TDD on reducers, tests on reducers not only speed up the development but also cover you on possible “silent” bugs on the state.Keep components simple and use component composition.Normalize the state with the use of Reselect libraryHandling complex store relationships (#386)Note from Dan AbramovDeleting is always tricky because there is no first class notion of a schema.
- These reducers will know when to remove IDs from foreign key fields because they know what the schema looks like.Dependencies I will consider in for managing complex form stateRedux-ormA small, simple and immutable ORM to manage relational data in your Redux store.It would be great if CRUD operations were managed with the model declaration with no need to write actions manually.Redux UIGood solution to separate the UI state from the application state.NormalizrLibrary suggested in the official redux documentation for normalizing the application state.Main dependencies for this projectReactReduxReact router v2Redux ThunkReact DnDReselectStyled componentsReact BootstrapBootstrap Material DesignJestConclusionRedux is a good solution for handling complex interface, it is very similar to flux architecture, but if I have to rewrite the application, I would do it in a different way.I would avoid to specify all the logic on the client, moving a part on the server side.A good approach I have seen in some projects, it is to dispatch the actions to the server and with a websockets connection, notify all the connected clients of the changes made.This way the client is responsible only to denormalize and normalize the state received by the server, handle the UI state and presenting the data.On the server side is much easier to handle relationships with an ORM provided by a web framework.This project has been of a great help to make me understand all the caveats redux can reserve for a medium size application.
I have been working on my first project with Redux for the last few weeks. An admin interface to manage and create questionnaires about patients data collection. When writing a small application…
Continue reading “Thoughts on Redux – Pietro Ghezzi – Medium”