51–60 of 63 posts
I've been experimenting with using a component to fetch data. The data to fetch is declaratively described as props. https://github.com/limscoder/react-wrangler It uses immutable and allows for time travel debugging.
Earlier quoted context omitted.
The beauty of redux itself is the lack of magic. It's essentially just a design pattern and is trivial to follow. So the "edit" part of your comment is key here: frameworks built on top of redux, including middlewares, store enhancers and stuff can definitely lead to an app that is hard to reason about with side effects happening in places you don't expect. IMO that ends up being the worse of both world: even with al…
Redux is difficult to reason about because side-effects can be triggered from anywhere in the application by middleware. If you're using something like redux-thunk, a single dispatch can cause both a store mutation AND trigger a side effect, which is confusing. I'd rather have those be 2 separate concerns. Those dispatches can be triggered from anywhere in the app, and multiple middlewares may trigger multiple side-e…
It's much easier to reason about, including side effects, while not being too magical.
If anyone's interested, I maintain a list of Redux-related addons and utilities over at https://github.com/markerikson/redux-ecosystem-links . Includes just about every vaguely-useful-looking middleware, action-generation utility, devtool, store enhancer, fill-in-category-here, that I've seen out there. (And yes, I already had redux-query in the list before this post :) )
Great work :)
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.
Earlier quoted context omitted.
Redux uses Event Sourcing. ES's trade-offs apply.
Its evented, not normally event-sourced. I don't know of many production uses of redux that also store the events for replay.
Why apply your event to the state, then somehow sync your state with the server.
Wouldnt it be simplier just to sync your events?
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,…
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/conne...
Earlier quoted context omitted.
Redux uses Event Sourcing. ES's trade-offs apply.
Its evented, not normally event-sourced. I don't know of many production uses of redux that also store the events for replay.
Why do i need to memoise my state to stop the react render loop from happening? Isnt my event the source of truth? Its much more then a DTO.
Once your application becomes "event centric" instead of "state centric" you start to actually break free of the procedural paradgim and really become functional reactive.
Redux to me is DDD and ES for non-programmers. My domain logic is the gatekeeper to my state, and as such, should be coupled together. I dont combine my aggregates, just the same way i dont combineReducers. Code smell much.
I love react, with the reusable components and the ergonomic of jsx but I really don't like what redux does to your code: it involves too much magic, you lose the concept of independent components and every change becomes a global one: everybody is notified of the inner state of each component … To me it just break all encapsulation and just lead to massive tangled code that is really hard to maintain … Edit: I want…
most people complain there is too much boilerplate!
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,…
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.
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,…
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.