Question

In an ongoing project my team is building a new web application that relies heavily on a rest api. As we decided to try react we naturally came to implement redux and a middleware, as we've read this is the way to go. However, further into the project, we noticed it would be a good approach to bundle all the api related logic into a common library. So from that point on, the frontend (react) got isolated from the logic querying the api. Due to a tight shedule we kinda rushed through this transition, leaving us with lots of redux code implementing the new library.

The new library manages the complete interaction with the api and even abstracts it away through different objects representing information compiled from different endpoints.

The question is: do we even need redux with this kind of architecture? It feels like completely duplicating the amount of code required for simple actions, due to the need of actions, reducers and the store. I really feel like the library we created holds its own store and should therefore be consumed directly from within the react components. Would this be considered bad practice?

Recently we've created a module of the library, that provides boolean toggles for whether a component should be visible or not. I'd actually like to build them right into the components (maybe as props). I guess I'm blinded by buzzwords on this matter, please enlighten me.

Was it helpful?

Solution

The question is: do we even need Redux with this kind of architecture?

If you can write your own you don't "need" anything.

If, as you've said, the library has become your go to for solving your API problems then yes you don't have any desperate need for Redux. No one needs any 3rd party code if they're willing to write their own code. Redux centers around putting your applications state in one object or state tree for you. If you're fine doing that yourself then sure you don't need Redux.

Another reason to go with your library would be you only want to use Redux for now. Later you want to be able to switch to a different way to persist state. It's really nice to have your own layer between your business logic and any 3rd party because that layer can isolate changes that need to be made when switching to another way to persist state.

Your business logic shouldn't even know you're using Redux even when you are. Treat Redux like a plugin. Then you can use whatever you like. Maybe even your own code.

Licensed under: CC-BY-SA with attribution
scroll top