4 ms·

Well, what's your solution? I mean, I've seen people drop redux into a single stand alone form for no reason other than they hadn't used react before, so they

Well, what's your solution? I mean, I've seen people drop redux into a single stand alone form for no reason other than they hadn't used react before, so they picked up a tutorial and the first thing it said to do was use redux. So, I'll happily agree that there's a whole lot of people using this without any need for it. ...but there is a need for it for some people, and for those people, what's your alternative? Raw react? Have you actually tried that? Passing all the props down from child to child to child to child? It's not awesome, I assure you. Are there redux alternatives out there that solve the same 'single source of truth' problem I've never heard of? What are you using? > There is no need for something to track "when, why and how your state was updated and what part of the application triggered the state update". ...or is that simply not a problem that some people have? I'll certainly agree to that; but then, why are you using react? If your UI isn't dynamic, why are you building an SPA? For fun? The good old MVC tech stack works perfectly well for static data display and forms. You know why react exists? ...because complex interactive forms are hard to do right, and because interactive user interfaces that do something more complicated than CRUD operations are actually quite difficult to do right. The MVVM pattern with data binding is the 'best' solution out there for most UI application framework, and react is successful specifically because it allows you to manage complexity by creating a hierarchy of components instead. That's a really powerful effective technique, there's no question. Redux lets you manage the state for that hierarchy in one place. It lets you build large react hierarchies and know exactly what state the UI is in at any point in time, in one place. Why? ...because managing state in 100 different locations is complicated. What you're seeing is tools to help manage complexity; but you only need to use them when your complexity reaches a threshold that triggers the need to use them. If you don't have a complex problem, you don't need complex tools to manage it. > has been turned into an over-complicated mess by the community of developers, by gluing it with over-complicated add-on technologies. What you're seeing is the application of tools to solve a problem that doesn't exist for the specific domain you're looking at. That doesn't mean they don't solve the problem; it just means your problem doesn't require that level of complexity management. It's quite frustrating. I hear the 'its too complex' as an argument from so many people about using libraries and tools, and want 'something simple' instead; but I've hardly ever heard someone pitch a viable alternative instead, just complaints. Too much tooling. Too much complexity. Over engineering. So, tldr: When you do have a big complex react application with complex UI interactions... what's the alternative? If there is one, I'd like to hear about it.

deleted 9y ago
[deleted]
shados 9y ago
> Have you actually tried that? Passing all the props down from child to child to child to child? It's not awesome, I assure you. I honestly think its not that bad. Elm essentially does that, and its arguably more productive than React's ecosystem. You might just want to optimize things a bit by making non-leaf components take a simple "model" prop (that contains all the properties they need) to reduce friction a little, but aside for that it might even make code better by forcing a more thoughtful component hierarchy. After all, if component A renders component B, then A really DOES depend on B's props. Magically having B kinds of hide dependencies. After all, short of using DI containers, if I have a function that calls another function that calls yet another, I DO pass arguments all the way down. And React components are semantically just functions.
- shadowmint 9y ago
  Only at a relatively trivial scale; and certainly, do that if your application is simple enough. There's probably a fair number of applications that clearly fall into the 'simple enough not to need redux' category. That's a good approach, seriously. You don't need redux at that point; don't use it. I'm not even suggesting such applications are 'trivial'; they probably just don't have excessively complex component hierarchies and interactions. ...but please read this really quite old article if you haven't before: http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/ http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/ This is an argument that has literally been made a hundred or more times before, and nothing has changed about it. Sure, this article is about dependency injection, but its essentially the same domain. You can argue that manually passing props is the same of 'poor mans' dependency injection, and it certainly has value in that there's 'no magic' in it. ...and certainly, you fall into the pit of pointlessness and frustrations when you use magic, but there's no convention to make the magic 'all work without surprises'; but the same issues still apply. Once the application reaches a certain size, the maintenance burden of the 'simple' approach becomes prohibitive. /shrug
  - 9y ago

deleted 9y ago

[deleted]

shados 9y ago

> Have you actually tried that? Passing all the props down from child to child to child to child? It's not awesome, I assure you. I honestly think its not that bad. Elm essentially does that, and its arguably more productive than React's ecosystem. You might just want to optimize things a bit by making non-leaf components take a simple "model" prop (that contains all the properties they need) to reduce friction a little, but aside for that it might even make code better by forcing a more thoughtful component hierarchy. After all, if component A renders component B, then A really DOES depend on B's props. Magically having B kinds of hide dependencies. After all, short of using DI containers, if I have a function that calls another function that calls yet another, I DO pass arguments all the way down. And React components are semantically just functions.

shadowmint 9y ago
Only at a relatively trivial scale; and certainly, do that if your application is simple enough. There's probably a fair number of applications that clearly fall into the 'simple enough not to need redux' category. That's a good approach, seriously. You don't need redux at that point; don't use it. I'm not even suggesting such applications are 'trivial'; they probably just don't have excessively complex component hierarchies and interactions. ...but please read this really quite old article if you haven't before: http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/ http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/ This is an argument that has literally been made a hundred or more times before, and nothing has changed about it. Sure, this article is about dependency injection, but its essentially the same domain. You can argue that manually passing props is the same of 'poor mans' dependency injection, and it certainly has value in that there's 'no magic' in it. ...and certainly, you fall into the pit of pointlessness and frustrations when you use magic, but there's no convention to make the magic 'all work without surprises'; but the same issues still apply. Once the application reaches a certain size, the maintenance burden of the 'simple' approach becomes prohibitive. /shrug
- 9y ago