5 ms·

I disagree about the jsx, but I do agree about Redux. React is beautiful in its simplicity, but Redux kind of throws all that out the window and adds all the mi

I disagree about the jsx, but I do agree about Redux. React is beautiful in its simplicity, but Redux kind of throws all that out the window and adds all the missing complexity back in. Granted, part of that is due to the relatively simple nature of React, but I do think there has to be (and likely eventually will be [I see your eye-rolling]) a better, more enjoyable way to handle state management.

city41 11y ago
How do you find Redux complex? I found I got the gist of Redux in a few minutes, and was very productive with it a couple hours. I find it much simpler than flux. What do you not like about it?
- icebraining 11y ago
  Glancing at the documentation, it seems to be essentially an implementation of the Memento Pattern, as described in the Gang of Four's book. I have to agree, it's fairly straightforward.
- moogleii 11y ago
  I have not used flux. It's not difficult to understand Redux, but the setup is not simple. Defining the constants, defining the actions, then defining the reducers. It's a lot of moving parts. Throw in the connection to react via react-redux, and it feels like you've had to repeat yourself in several places, not exactly, but enough to be annoying.
rco8786 11y ago
Likely because the stateful portion of any system is going the be the complex part.
tjholowaychuk 11y ago
I think this is more of a documentation issue. Redux itself is simple, it's just the barrage of functions you need to use to get anything going that get in the way IMHO. A little layer on top would make it pretty nice in that sense. Redux effects and friends are simple too but suffer the same issue, they're so functional that they can be hard to reason about. You really need higher level abstractions to hide that stuff or it gets unwieldy fast. I think it's the typical 80/20 – hard things are easy with React/Redux, easy things are sometimes hard.
acjohnson55 11y ago
I actually find it to be the opposite. Developing with Redux, you can actually throw away most of React's API. In my app, React basically acts like a functionally pure rendering layer. It definitely has a learning curve, but the very simple data flow makes it pretty straightforward, once you've learned what each layer does.
- moogleii 11y ago
  That's definitely the Redux dream I'm trying to achieve, but as I mentioned in a comment elsewhere, it feels like there is a lot of initial setup. And with each new container, the setup process just starts over. I haven't craved TypeScript in awhile, but for whatever reason, Redux has rekindled the desire (and I know it can be done, I just haven't gotten around to it).
Matthias247 11y ago
I found it to be quite like the other way around. I thought React is a quite decent view library (with medium complexity, if you try to understand and use all the lifecycle methods and think about suitable keys for reconciliation), but I found Redux a bit too primitive for my taste and decided against using it. Reasons where that I don't think storing all state in a single object is a good design idea and that state for me is not only about serializable objects (e.g. I often need to keep promises and other stuff around). I understand that it enables some things like hot reloading and time travel debugging, but thats not the highest priority on my nice-to-have list. After experimenting with React I'm now using angular2 for my project and apart from some bugs that are left I'm quite happy with it. Architecture-wise I put all state (serializable or not) in multiple-independent plain JS service objects which are injected into the view components through ng2 dependency injection. And they expose their state through observables, which together with things like async pipes makes reactivity really easy.
- moogleii 11y ago
  I might be misunderstanding you, but if you mean handling state at run-time, I feel like handling it in multiple places would be more complex, no? Otherwise, you can actually define state handlers (or as redux calls it, reducers) in multiple files as well, so that each subsection of state is being handled independently.
  - EvanPlaice 11y ago
    Nope NG2 services are essentially just singletons that can be injected into any component. You can specify a server as an application wide provider (ie attach during bootstrap) or a component-specific provider. Once a service is injected into a component all you have to do is set subscribe a variable to the service's observable. It the variable is bound to the view, it should update automatically. Event handling can be setup to update the observable by calling .next(). NG2 uses Rxjs (Reactive Extensions for JS) which is just the observable structures plus a ton of functional extensions (ie equivalent to reducers) that can add all sorts of inline transforms. Ex flatMap, filter, debounce, etc. The Rxjs observable API is almost identical to promises. Except you call .subscribe() instead of .then() and the subscription can be disposed of at any time (ie promises always run to completion). Rxjs uses hot and cold observables. For cold, subscriptions each have their own independent state and disposing of the subscription will stop the observer from retrieving further updates. Hot observables publish updates to all observers and keep updating even when there are no subscribers. Basically, cold observables are like 'on demand' viewing whereas hot is like watching a 'live stream'.

city41 11y ago

How do you find Redux complex? I found I got the gist of Redux in a few minutes, and was very productive with it a couple hours. I find it much simpler than flux. What do you not like about it?

icebraining 11y ago
Glancing at the documentation, it seems to be essentially an implementation of the Memento Pattern, as described in the Gang of Four's book. I have to agree, it's fairly straightforward.
moogleii 11y ago
I have not used flux. It's not difficult to understand Redux, but the setup is not simple. Defining the constants, defining the actions, then defining the reducers. It's a lot of moving parts. Throw in the connection to react via react-redux, and it feels like you've had to repeat yourself in several places, not exactly, but enough to be annoying.

rco8786 11y ago

Likely because the stateful portion of any system is going the be the complex part.

tjholowaychuk 11y ago

I think this is more of a documentation issue. Redux itself is simple, it's just the barrage of functions you need to use to get anything going that get in the way IMHO. A little layer on top would make it pretty nice in that sense. Redux effects and friends are simple too but suffer the same issue, they're so functional that they can be hard to reason about. You really need higher level abstractions to hide that stuff or it gets unwieldy fast. I think it's the typical 80/20 – hard things are easy with React/Redux, easy things are sometimes hard.

acjohnson55 11y ago

I actually find it to be the opposite. Developing with Redux, you can actually throw away most of React's API. In my app, React basically acts like a functionally pure rendering layer. It definitely has a learning curve, but the very simple data flow makes it pretty straightforward, once you've learned what each layer does.

moogleii 11y ago
That's definitely the Redux dream I'm trying to achieve, but as I mentioned in a comment elsewhere, it feels like there is a lot of initial setup. And with each new container, the setup process just starts over. I haven't craved TypeScript in awhile, but for whatever reason, Redux has rekindled the desire (and I know it can be done, I just haven't gotten around to it).

Matthias247 11y ago

I found it to be quite like the other way around. I thought React is a quite decent view library (with medium complexity, if you try to understand and use all the lifecycle methods and think about suitable keys for reconciliation), but I found Redux a bit too primitive for my taste and decided against using it. Reasons where that I don't think storing all state in a single object is a good design idea and that state for me is not only about serializable objects (e.g. I often need to keep promises and other stuff around). I understand that it enables some things like hot reloading and time travel debugging, but thats not the highest priority on my nice-to-have list. After experimenting with React I'm now using angular2 for my project and apart from some bugs that are left I'm quite happy with it. Architecture-wise I put all state (serializable or not) in multiple-independent plain JS service objects which are injected into the view components through ng2 dependency injection. And they expose their state through observables, which together with things like async pipes makes reactivity really easy.

moogleii 11y ago
I might be misunderstanding you, but if you mean handling state at run-time, I feel like handling it in multiple places would be more complex, no? Otherwise, you can actually define state handlers (or as redux calls it, reducers) in multiple files as well, so that each subsection of state is being handled independently.
- EvanPlaice 11y ago
  Nope NG2 services are essentially just singletons that can be injected into any component. You can specify a server as an application wide provider (ie attach during bootstrap) or a component-specific provider. Once a service is injected into a component all you have to do is set subscribe a variable to the service's observable. It the variable is bound to the view, it should update automatically. Event handling can be setup to update the observable by calling .next(). NG2 uses Rxjs (Reactive Extensions for JS) which is just the observable structures plus a ton of functional extensions (ie equivalent to reducers) that can add all sorts of inline transforms. Ex flatMap, filter, debounce, etc. The Rxjs observable API is almost identical to promises. Except you call .subscribe() instead of .then() and the subscription can be disposed of at any time (ie promises always run to completion). Rxjs uses hot and cold observables. For cold, subscriptions each have their own independent state and disposing of the subscription will stop the observer from retrieving further updates. Hot observables publish updates to all observers and keep updating even when there are no subscribers. Basically, cold observables are like 'on demand' viewing whereas hot is like watching a 'live stream'.