3 ms·

Everyone says redux and react make for great component isolation. How many of you people who use this combo can swap redux out at a whim, for another state man

by weq 10y ago

Everyone says redux and react make for great component isolation. How many of you people who use this combo can swap redux out at a whim, for another state management tool? How many of your components have been modified to work with the opinions of redux? Why do i need to couple my components with redux using connect()? In my experience, redux and react on there own present decent patterns to simplify UI experience, but ive never seen a discussion that involves them that doesnt couple one with the other.

nikcub 10y ago
There are two ways to make them more loosely coupled: 1. declare your connect's in a separate file that import your component and live alongside your containers, actions, reducers, etc. 2. write your own connect HOC that brings in redux. If you read the connect source[0] you'll find that it is actually really simple at it's core - but it is over complicated by having to account for so many use cases - your own HOC could/should be ~30 lines I now use 2. because it produces proper separation and makes it easy to swap out components later on (or use more than one). [0] https://github.com/reactjs/react-redux/blob/master/src/connect/connect.js https://github.com/reactjs/react-redux/blob/master/src/conne...
mlsarecmg 10y ago
Swapping the management would be difficult, they all have their own patterns and implementations. But swapping Redux is absolutely possible. The logic sits in a self contained container which you can plug into literally every framework under the sun. The "connect" you're talking about is in place for React, Ember, Angular, Vue, Knockout, Mithril, Cycle, etc. Redux is also the closest you can get to a true universal app, because you can share it between code-bases (desktop app, web app, mobile app, backend even if you need). We deploy a library based on this. It has reactive/changing datastructures that need to be presented visually. It runs on redux internally, and that is what makes it possible for our customers to embed it, no matter which framework they choose, even if it's JQuery. They form a simple dress and get served the properties and actions to display and excute. "Connect" makes their stuff aware of changes.
TheAceOfHearts 10y ago
We try to keep our views and business logic reasonably well isolated. You see something in larger REST APIs, where the business logic is wrapped in a service object with is kept separate from everything else. Recently we had a small "hackathon" event to evaluate GraphQL and Relay. Once the GraphQL server was up and running, getting Relay working with our app was really easy. Unfortunately, the migration path for adopting it heavily didn't seem to be worth it for us.

by weq 10y ago

nikcub 10y ago

There are two ways to make them more loosely coupled: 1. declare your connect's in a separate file that import your component and live alongside your containers, actions, reducers, etc. 2. write your own connect HOC that brings in redux. If you read the connect source[0] you'll find that it is actually really simple at it's core - but it is over complicated by having to account for so many use cases - your own HOC could/should be ~30 lines I now use 2. because it produces proper separation and makes it easy to swap out components later on (or use more than one). [0] https://github.com/reactjs/react-redux/blob/master/src/connect/connect.js https://github.com/reactjs/react-redux/blob/master/src/conne...

mlsarecmg 10y ago

Swapping the management would be difficult, they all have their own patterns and implementations. But swapping Redux is absolutely possible. The logic sits in a self contained container which you can plug into literally every framework under the sun. The "connect" you're talking about is in place for React, Ember, Angular, Vue, Knockout, Mithril, Cycle, etc. Redux is also the closest you can get to a true universal app, because you can share it between code-bases (desktop app, web app, mobile app, backend even if you need). We deploy a library based on this. It has reactive/changing datastructures that need to be presented visually. It runs on redux internally, and that is what makes it possible for our customers to embed it, no matter which framework they choose, even if it's JQuery. They form a simple dress and get served the properties and actions to display and excute. "Connect" makes their stuff aware of changes.

TheAceOfHearts 10y ago

We try to keep our views and business logic reasonably well isolated. You see something in larger REST APIs, where the business logic is wrapped in a service object with is kept separate from everything else. Recently we had a small "hackathon" event to evaluate GraphQL and Relay. Once the GraphQL server was up and running, getting Relay working with our app was really easy. Unfortunately, the migration path for adopting it heavily didn't seem to be worth it for us.