I recently played the role of a front end developer. You know, I’m not one in a broad sense. I have not my head wrapped around CSS and visual stuff. But I made it reasonably well using the following toolkit:
- ReactJS - A javascript library for building user interfaces
- Redux - a predictable state container for JavaScript apps
- Material-UI - A set of React Components that Implement Google’s Material Design
This combo is pretty high level and you end up with a package.json
like this:
Most of it was generated by Create React App because to me it is so much to setup, that I picked up the easy way. You can use Webpack - I once used to setup/build a Angular 2 app - but it’s totally non standardized and every example on the internet just look totally different from each other.
From this package.json
above, I would like to quickly highlight redux-thunk, Lodash and isomorphic-fetch. They are must have for every Redux/React apps!
Redux
The main point of this post is Redux (Hold on, it’s not another Redux introduction, if you want to understand it see this blog post by Tal Kol). I like it and should use it every app with ReactJS from now on, there are couple alternatives that I haven’t tried, like Fluxible, Alt and Relay. But Redux is good to go as long you are ready to write tons of code.
The repetition from Redux came into play when I had to fetch different entities from the server and for all of them, keep track of at least 3 states: LOADING
, RECEIVE
and FAILED
. You can call it with different names, but they express something like this.
If you are familiar with Redux you know it will requrie a reducer case
, an action creator function, and a action type constant. And of course the same series of dispatch for every entity your are trying to load form the server. Something like:
This pattern repeats all over the app. The abstraction code is pretty big, please refer to the full source at THIS GIST. It’s called ReduxFetcher
.
To summarise it, the code creates action type names out of entity
argument. I’ve also used specific action type names for every operation.
And action creators that refer to these actions when needed:
Finally, the abstraction provides fetch
, filter
, list
and update
dynamic actions. See the list implementaion:
The result was a high level of code being reused for 8 entities. The abstrated actions can also be wired to componetes using mapdispatchToProps and used as any function inside components.
Conclusion
Redux is awesome, I feel I do better Flux than used to do MVC in the old times of JSP, Spring, Struts, JSF, etc. You feel not only that you understood whole Flux, but also you are able to fully implemented it.
Of course my abstraction got a problem, it is mine in the sense that it was written/designed to work with my application. After finishing the project I realized there are couple options out there to do what I did:
- reux-crud
- redux-crud-async
- redux-entity
- Feeble - not exactly the same thing, but the same approach
It was ok for me to find those libs only at the end of the project (went live already), it gave me the sensation that I wasn’t so wrong trying to aggregate and centralize these Redux pieces in the same place.
Hope you liked! Cheers!