Redux Light and Universal endpoints

This blogpost is still being written and isn't finished, but I already put it here for you to read.

Redux adds a lot of layers and boilerplate, which increases time-to-context. Here are the pro's and cons of Redux in my opinion. In this post, I'm showing the form of Redux (and GraphQL/REST) I like the most: Redux Light, I'm calling it. Here are my considerations before I decide which to use.

Redux Redux Light
Seperation of Redux and your component.
Your component doesn't know anything about Redux.
You create inheritance and layers.
This makes time to context rather slow
Faster time to context. Composition over inheritance
Lots of boilerplate. MapStateToProps, MapDispatchToProps,
and even ActionCreators. Lots. Of. Boiler. Plate.
Minimal boilerplate, and still clear what you're doing.
No overhead. Your components only sees what it needs There's some overhead, but this doesn't matter a lot for efficiency

Code sample Redux vs. Redux Light

Coming soon

Universal Data Principle

You can have a very specific and exact way of bringing data to your app, but you can also distribute certain data universally throughout your app. The latter has a big advantage: a clear convention of data structure, and boilerplate reduction. The only problem is overhead of data in your screens.

TODO: Write about Redux CRUD

Discover Redux-CRUD. Create CRUD functions for Redux without all actiontypes, if it seems better without. Maybe just fork this repo.

Redux Light and Universal endpoints
Share this

Subscribe to Karsens