Blogged Answers: Redux - Not Dead Yet! #26
Comments
|
Original author: Eric Andre @ericandre I would like to point out that Redux can be used without React. Most of the concerns above are always tied to Redux + React. I have currently been working on a game engine that uses Redux for state management and the project does not at all use React. Guess what? It works great. Alll those specific examples of React has a new context API that could replace Redux can only even begin to be an argument if you are specifically using Redux with React. |
|
Original author: deadcoder0904 @deadcoder0904 As a note, New Context API does not replace Redux at all. It doesn't have Time Travel Debugging & for more info checkout https://www.reddit.com/r/re... & can result in something like https://twitter.com/coderit... |
|
Original author: Eli It can, check out react-waterfall... |
|
Original author: BS-Harou @bsharou Also Redux is so much more than just the library itself. The whole ecosystem built around is just not something to be easily replaced. Handling complicated async stuff without redux-saga is pain, understanding the application flow without redux-logger is pain, managing history without react-router-redux is pain. Redux is love, redux is life. |
|
Original author: Eliseu Monar @eliseumds Exactly! We're using Redux and Redux Saga on the server-side to manage a real-time content moderation queue. |
|
Original author: Eric Andre @ericandre Yeah, even Angular projects are using Redux. |
|
Original author: Dziamid @dziamid Interesting, care to blog about it? |
|
Original author: Mike @emshots LONG LIVE REDUX!! ✊ |
|
Original author: deadcoder0904 @deadcoder0904 Well I already did. Its another state management library. It can't provide all the benefits Redux provides. Its like if you're not using a framework, then you're making one. So if you're not using Context API, then you're using it through something like Redux/Mobx |
|
Original author: Eli you are right, the context api replaces the old context which is already used by most state management frameworks. |
|
Original author: Matthew Barnden @matthewbarnden The KISS principle being executed correctly will always have the biggest impact and see the most adoption. We saw this with jQuery and also with React. Whilst I agree you can use Redux elsewhere and do a bit more with it, many I feel use Redux for state management. The stable version of Context API now makes this clear and simple. The only people that won’t be adopting it for there state management needs are some pride filled devs that feel some sense of achievement from understanding the tangled, bloated and complex mess that is Redux. |
|
Original author: Hà Nguyễn @river11576 one solution for that bloated tree is some library like recompact and back to using HOCs, such as the injector provided by mobx |
|
Original author: Hà Nguyễn @river11576 say whatever you want, but I find it hard to believe that 10 years from now someone will look back at redux and think "what a beautiful library that shaped the way modern applications are architectured". What's likely to happen is that it goes into history as "remember that time people used to write code that way?". |
|
Original author: Hà Nguyễn @river11576 I find it funny that the redux community thinks they've solved async programming for the first time in history. Wow redux-saga is the best way to write async code huh? How do those other programming languages do async programming I wonder. |
|
Original author: BS-Harou @bsharou I mean sagas themselves do not originate in javascript. Anyway, it is not just about if there is a better way of doing things but if there is a solid js library with wide adoption to use. I think the js community is doing good job of taking the better ideas from other languages and implementing them and of all the solution that made its way to javascript I find redux-sags and rxjs to be so far the best out there. Of the two, sagas are imho easier when it comes to keeping the application logic in your head, but I have nothing against rxjs. That said, if someone comes up with something even better that gets the adoption and depth of ecosystem as redux has right now I can see myself moving on, it's just that there is nothing yet that would blow me away. |
|
Original author: RyanVice @RyanVice Do you feel the same way about CQRS? |
|
Original author: RyanVice @RyanVice KISS is a function of the problem you are trying to solve. Do you care to share what you feel the main benefits of redux are? I think team\developer values are a really important part if Redux makes sense. |
|
Original author: Jeff Weinberg It’s important to note how great Redux is for collaboration, in that it is very easy to onboard a new developer to a Redux project if they are familiar with the approach. It's going to be hard to say the same for a home baked approach using the context API |
|
Original author: Matthew Barnden @matthewbarnden KISS is a principle that encourages you to try and remember to solve your problems simply and clearly, I think from my response you can see I’m not overly a fan of Redux, maybe as some other commenters have said, mainly when people jump for it to early and over complicate their solution. I agree that is important that a team are all happy and aligned with the library’s and frameworks they use, if this is what you meant. I just really think that we will see a drop off in the amount of Devs using Redux as they now have a simpler more coherent option for state management in React. |
|
Original author: RyanVice @RyanVice That's a good description of KISS and I think FLUX was a great example of a company applying KISS to solve a very complex problem in a simple way. Facebook introduce FLUX to solve the issue they were having with keeping their notification count accurate across multiple teams in a very complex App. While 2 way data binding and MV* are both much simpler approaches than Redux they result in more complex solutions to the problem Facebook was facing as the data flow was complicated with models observing models making their data flow harder to reason about. Redux is an optimization of the flux approach with an eye towards improved developer tooling. While using an immutable model could be seen as more complex (less simple) than having a model that mutates, it offers huge benefits on the performance side because it allows you to avoid deep dirty checks in React. To know foo is dirty when only foo.bar.biz.baz has changed we only need to do this if (nextProps.foo !== this.props.foo) I'd argue that this is much simpler approach to a more common issue in complex apps than the other viable options (deep compares or observables). That's a huge gain for adding the immutability. If you implement idiomatic redux as your app grows complex a lot of the problems that are harder to tackle with simpler approaches like 2 way data binding, mutable models, etc... can become very difficult to solve. This is why you see so many folks rewriting 3 year old angular 1.x apps in React Redux even though it's a more complex data flow approach. I'm not going to try and predict the future popularity of frameworks, although I've got a good track record of doing so, but I think there are some clear benefits to Redux today and if those align with your requirements and values then you can get big ROI out of it as I've seen on many, many projects. I'm not sure I'm following your "more coherent" argument. Redux is a very opinionated approach and if anything having more, strict rules to follow would lead to a more coherent architecture not less. That said on one project I'm currently using and enjoying using Apollo and I feel the future is bright there so who knows what's down the road but you'd be foolish to bet that any UX approach would still be a front runner in 5 years. That's never happened through my 20 year career. |
|
Original author: Matthew Barnden @matthewbarnden Yes I agree that maybe the coherent comment was being slightly OTT. I am a firm believer in trying to get the right tool for the job / size and situation. I don’t really subscribe to this whole idea of tech being killed off etc, I’m much more of a product focused dev to be honest and want to focus on what really benefits the product. I have worked in different environments and team sizes digital agencies / corporate / start ups, the correct approach taken that brings the most success would be vastly different because of the product and situations needs. I did however get tired of the constant Redux evangelists, so I am sorta venting slightly 🙂, but I also do believe as said before that allot of people will start choosing to use the Context API rather than feeling that they have to jump into Redux just to manage some state. |
|
Original author: Evan Gillogley @evangillogley yup. I use ngrx in Angular - not exactly redux, but pretty much same idea |
|
Original author: RyanVice @RyanVice That doesn’t really make sense to me because that’s not what what context is intended for and there is no where near feature parity with redux “When to Use Context ... Don’t use context just to avoid passing props a few levels down. Stick to cases where the same data needs to accessed in many components at multiple levels.“ |
|
Original author: Matthew Barnden @matthewbarnden Which would be my intention. |
|
Original author: InDev @IndevWeb I write article about React without redux, because a new context api, can send state for childrens components, if use redux only it, you not need use redux :) |
|
Original author: Hà Nguyễn @river11576 no, that I think is a good principle, may be more useful in the backend though. |
|
Original author: Hà Nguyễn @river11576 the new mobx flow API seems to take some inspiration from redux-saga, you may find it useful. Personally I don't feel async programming should be that much of a topic when it comes to front-end architecture given people have been doing it for years. I'm not too impressed by generators, always thought it's just a different syntax to do the same thing, more into the power of rx. |
|
Original author: RyanVice @RyanVice What would be your preferred pattern for solving Facebooks notification bug that they were fighting for years before going to a cqrs style approach which they called Flux? |
|
Original author: BS-Harou @bsharou Personally I find mobx to be a bit too all over the place for my liking, but I guess some competition is always healthy. |
|
Original author: RyanVice @RyanVice For global data this is not an approach I'd recommend to any of my clients. I'd recommend just using CommonJs and injecting stateful services (angular style) for sharing cross cutting concerns over using React's context. And assuming you are going to following their recommendation then you would only use context in cases where their is a heavy sharing need which would leave you with a bit question mark around the rest of your state management needs. I couldn't imagine recommending context as a state management solution without some lib sitting on top of it... something like Redux. |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: Michał Urbanek @kremuwa |
|
Original author: B650 maybe im in the camp of "i used it before i knew it" and now i'm systematically pulling it out entirely save for a few cases where i need global stuff. My app looks much better with a LOT less redux. I;m making ajax calls directly in components and keeping the data local. Honestly, redux is just a way to pass an update event when a global var changes and other things need to "know" about. Lets not lie..... its REALLY complicated to do this and requires a lot of constructs that make reading the code hard. And following all the labels/names HARD. I wish web was real-time and rendered many times a second seamlessly. One would not need a event system like this. You just change the variable or don't and the next frame gets rendered either way. Web is slow, buggy, and exceedingly complex for how little it does. I don't blame redux for this, its a structured way to organize this chaos, but its still chaos. |
|
Original author: Steve john Thank you for this information, I appreciate your effort, please keep us update, ..... |
|
Original author: Robert Christian What specifically do you dislike about it? And what do consider to be a better alternative? |
|
Original author: Hà Nguyễn @river11576 it's hard to pinpoint because redux is an amalgam of things. Probably what I dislike the most is how it shoehorns event sourcing into our codebase, in such a way that it introduces primitives that are alien to javascript (actions and reducers, not symbols and functions and classes). Using redux means your code becomes a bunch of l̶o̶o̶s̶e̶l̶y̶ ̶implicitly coupled, hard to type annotate, functions. Not everyone needs even sourcing, and if you do, maybe it makes more sense to do an npm query for something like "event bus", or "reactive stream" and not something under the category of "global" "state management" bs. But redux is not just that, it's a whole bunch of half-arse things: like state machine? here are some "state pattern" (hint: not fsm). Like immutable data? here is immutable data, but it does not play well with type checkers. Like observer pattern? Here is a minimal implementation that's obscured from you. Like dependency injection? here is a hoc, you can only inject stuff into views though, so your core logic is still in deep shit... When we started with redux there was a popular argument about being easier to debug with the devtools. I always thought it's kind of silly because you should choose the framework wherein your code makes the most sense and is easy to maintain, then the community can come up with whatever debugger to support that framework, not the other way around. Mobx for example never bragged about traceability or event sourcing, yet there is a devtools extension that enables time travel in it. My ideal model of programming would be something like cyclejs in which the view layer is completely stateless and all the props are immutable. You achieve reactivity by having your props constructed as either an observer or observable, and just connect them together. This model of programming is universal and emerging in the mobile development scene as well. It's a bit harder to program because you never write statements to do things, instead constructing small programs in the form of observable streams, then connect them together, which is closer to lazy functional programming. A less extreme approach would be or course mobx, with unidirectional data flow in mind, no need a silly library to tell us how to code. A more bare bone approach is wrapping react contexts with hoc yourself and stay close to react primitives. You should be careful going down this route because you may end up having your core logic modules dependent on react API (setState being the obvious candidate). There are a few new "state management solutions" that take this approach (unstated or smt like that), but redux left such a bad taste in my mount that I now just avoid that whole category of lib altogether. Disclaimer: still maintain production code in redux, don't have much choice at work. |
|
Original author: SynergyTop LLC @synergytop Thank you for this information, I appreciate your effort, please keep us update. |
|
Perhaps too late to comment, but there is a sentence that never ended: I'm evaluating state management libraries and have been enjoying your blog posts, wish I knew where this was leading :) |
|
@ercgrat : huh, so I did! I assume I was going to say "Once the API is ready, we plan to ship it as part of Redux Toolkit itself", which is what we did: |
|
@Subham-Maity That article feels like it's making a somewhat mistaken comparison. The examples are comparing legacy hand-written Redux data fetching code vs React Query, when the proper comparison would be using RTK Query for the data fetching: |
No description provided.
The text was updated successfully, but these errors were encountered: