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.

  • 1
    I haven't seen your project so I can give you only one answer, I don't know.
    – Andy
    Aug 13, 2016 at 13:59
  • Why'd you need to see my project to tell me something about redux vs library? Aug 13, 2016 at 14:08
  • Because I have literally no idea how the library is different from or same as the Redux library. Maybe your library is only a wrapper for the Redux library but uses it internally. Maybe if you remove Redux you will have to write the Redux logic yourself. Maybe. I cannot know that without actually seing the code.
    – Andy
    Aug 13, 2016 at 14:12

1 Answer 1


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.

  • Another reason to go with your library would be you only want to use Redux for now That is exactly the reason. We wanted to create an abstraction layer between our api and the frontend we are using. I'm thinking we are "overwriting" the redux part here. Is it generally "good style" to call our api directly from within components or would it be better to pass it down through props? I feel like while this coding style makes it much simpler for us to work, it might subvert what React or Redux stand for. Aug 15, 2016 at 13:18
  • 1
    Isolating a detail like redux only subverts it's desire to make you dependent on it. I say your better off in control than being controlled. Aug 15, 2016 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.