5 ms·
> - Do not use redux until you know React well. You might not need it. Indeed, I would say not using redux at all. I never understood why redux has become so p
by bespoken 8y ago
> - Do not use redux until you know React well. You might not need it.
Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app..
I'm now using "unstated" for client store. What a breeze of fresh air!
- deleted 8y ago[deleted]
- bespoken 8y agoHere we go again, not using redux makes you a noob developer.. So in your mind it's redux vs spaghetti? No other options, ever?
- deleted 8y ago[deleted]
- flwralex 8y agoReally sorry to call you noob. You may have more experience dealing with Redux codebases from me, but in any case I was arrogant and I'm sorry.
- rvSGK4 8y ago> not creating own modular framework instead of using the marketing-driven library/bloat that is called React. > calling others noobs.
- deleted 8y ago[deleted]
- yakshaving_jgt 8y agoAh, it's poor design because you don't understand it? Right.
- bespoken 8y agoNo, not right. I have work on a daily base with redux unfortunately. Redux is not too hard, but it's poor in design. Also you will have to give up redux soon, the hype is over and better things are at the horizon. There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. Do you really think redux is the holy grail of stores? If you're really smart enough to understand it, think a little deeper about the design, it really sucks. Try unstated, or is that too simple for you? Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
- mhluongo 8y agoYou haven't explained why it's "poor in design".
- lkschubert8 8y agoIt seems to be they just don't like it.
- yakshaving_jgt 8y agoWow. What an incredibly ignorant and embarrassing point of view. > Redux is not too hard, but it's poor in design. You have not once yet stated why it is "poor in design". > Also you will have to give up redux soon, the hype is over and better things are at the horizon. I do not care for hype. I am embarrassed for you that you use hype as a measure of a technology's quality. > There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. You are projecting a point of view onto me that I do not hold. Does this argument tactic usually work? > Do you really think redux is the holy grail of stores? No. I do not hold it in higher regarded than what I believe is merited. > If you're really smart enough to understand it, think a little deeper about the design, it really sucks. Once again, you say that "it sucks" without giving a valid reason. Do better. > Try unstated, or is that too simple for you? Unstated? If you mean "stateless", then I'm not sure what there is to try. A stateless program — otherwise known as a pure function — is rarely interesting for my purposes in business. In all cases, my programs required some persistent state to be modelled. > Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off? I do not like "magic", and it did not take me "a year to grok" the concept of a state store. Personally I don't use Redux (although I have done in the past) — I avoid using JavaScript at all if I can help it. Where I need complex UIs, I use Elm. Redux is a JavaScript state store heavily inspired by Elm. It's basically the same, minus type safety (so it's worse). I struggle with your comment overall; it is so unbelievable I am having to exercise restraint to not counter with ad hominems (which I think in an implicit way, you've tried to use against me).
- flwralex 8y agoI would be happy to show you how to use redux, without switch statements and even without reducers. It's not that hard, and if you don't like it, just use other state management libs. But don't call it poor design - it has 2 methods.
- wallawe 8y agoCan you point to any writeups on this? Would love to reduce the boilerplate a bit, while still needing a global state management tool for a smaller app.
- flwralex 8y agoHi, if you mean how to get rid of switch statements, you can check my comment bellow - about "action-reducer". I've seen https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux and it's close to what I do. Also you can check - https://github.com/reduxjs/redux/issues/1167#issuecomment-382014567 https://github.com/reduxjs/redux/issues/1167#issuecomment-38...
- wallawe 8y agoThanks so much, I love the pattern in the second link you shared
- acemarke 8y agoHi, I'm a Redux maintainer. Here's a few resources. First, the docs already have a page called "Reducing Boilerplate", which shows patterns like writing a function that accepts a lookup table of reducers [0]. Second, a while back I wrote a pair of posts called "The Tao of Redux" [1] [2]. Part 1 discusses the implementation and intent behind how Redux is meant to be used, and Part 2 looks at why common usage practices exist. As part of that, I pointed out that you can use whatever logic you want in your reducers, and as much or as little abstraction on top of Redux. Switch statements are simply the most obvious way to handle multiple values for a single field, but you should feel free to use whatever approach you want. Third, we've recently created a new package called `redux-starter-kit` [3]. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action types or action creators by hand. I'd encourage you to try it out and let us know how well it works for you. Please let me know if you've got any other questions I can help with! [0] https://redux.js.org/recipes/reducing-boilerplate https://redux.js.org/recipes/reducing-boilerplate [1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [3] https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/
- RealDinosaur 8y agoRedux still baffles me. I've implemented it 4 times, and it still confuses the hell out of me. MobX is a much better fit for most react apps IMHO. Redux could be good, if you have a database [id] driven application, but for most people is way too restrictive. If you are working in a small team, and are using Redux, you are probably making life harder than it has to be.
- flwralex 8y agoWhen Redux stops to buffles you, might be the good time to give advice about it. You might implement it 20 times, but if you don't understand it, every time will be pain. Redux can be life saver even for single developer, so team size dosen't matter. Would be funny to say, I've tried 4 times to tie my shoes, but didn't go well, so you shuldn't tie your shoes... So much hate, whithout any reason is what buffles me.
- kowdermeister 8y ago> but for most people is way too restrictive This is the point of redux. If you don't have these restrictions, then state will be all overt the place, race conditions, side effects will make your life much harder as the app matures especially with multiple developers.
- acemarke 8y agoHi, I'm a Redux maintainer. Any specific aspects you're having trouble with? Happy to answer questions.
- dkarl 8y agoAs a back end developer, Redux had instant appeal to me, because I've written apps that managed state by generating events asynchronously, serializing them, and using each one to update state in turn, generating a series of discrete state snapshots that were used to serve read operations. In doing so I reinvented Flux without realizing it (as everybody does when they structure an application that way.) When I encountered Redux, its concepts mapped exactly onto the concepts I already knew, so it was easy to get started. I had written reducers before, though I didn't call them that. After previous brushes with front-end development, I was excited to have a clean conceptual separation between state management and rendering the DOM. Managing that relationship seemed to be a place where even expert front-end developers got lost, so I was happy to have a radically simple solution. I can see why the Flux concept would seem arbitrary and overengineered if you hadn't been forced to solve that particular problem before. For me, the baffling parts of Redux were the ones that were specific to React, because my understanding of React was very shallow. The amount of React I had to learn to understand React/Redux felt like way more than I would have needed to learn to write an app without Redux. But for me, it was worth the effort to be able to use Redux for state management.
- acemarke 8y agoI recently wrote a post called "The History and Implementation of React-Redux" [0]. It covers the basic process of how Redux works with a UI, the benefits of using React-Redux, and the specific implementation details of how it optimizes React rendering updates for you. [0] https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
- acemarke 8y agoYou've never "needed" to use switch statements - you're welcome to use whatever conditional logic you want in your reducers. Many people prefer to use lookup tables of functions to handle different action types. Reducers are one of the main points of Redux, because separating the idea that "something happened" from "here's how the state updates in response" is key to allowing things like the Redux DevTools to work. The point of `mapStateToProps` is to allow you to specify "here's the data this component needs from the Redux" store, so that `connect` can take care of the work of subscribing to the store and only re-rendering your component when it actually gets new data. See my post "The History and Implementation of React-Redux" [0] for more details. Finally, please check out our new `redux-starter-kit` package, which helps simplify several common Redux use cases [1]. [0] https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor... [1] https://redux-starter-kit.js.org https://redux-starter-kit.js.org
- Jare 8y ago> separating the idea that "something happened" from "here's how the state updates in response" is key The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and analyze. The ideal? I want to define a function with its parameters and that function performs the logic and data massaging it needs to. When I want that behaviour to trigger because something happened, I want to describe a call to that function with the right parameters with minimal scaffolding. Ideally, it would look exactly like I call that function, and the machinery that would turn that into posting an action that eventually reaches a reducer would be hidden from my sight. I do not want that scaffolding polluting my code. Defining string names for my functions? They are functions, they already have a name. Defining action objects to store the parameters? I already have a place for that, it's called "function parameters". I don't know what sort of magic could provide this seamless integration of the reactive patterns into javascript, sort of some transpilation machinery. But I really, REALLY do not want it visible in my code.
- 8y ago