6 ms·

Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?

WorldMaker 8y ago
Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux itself is just the "stuff inside the oreo" gluing React to all my interesting "epics" describing high level functionality in the applications. It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well.
- kerkeslager 8y ago
  > From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux itself is just the "stuff inside the oreo" gluing React to all my interesting "epics" describing high level functionality in the applications. The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS. > It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well. Don't sully UNIX philosophy by comparing it to Redux! UNIX is such a different environment from JS space that it's hard to really even compare the two, but at the very least I think we can agree that "Doing one thing well" in UNIX means not creating a bunch of new problems that you need other tools to solve. [1] https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8 https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...
  - WorldMaker 8y ago
    > The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS. Yes, and before I was using React+Redux+Redux-Observable I was using Cycle.JS and everything was RxJS and/or Xstream (an RxJS-like) observable-based patterns. As I said, this stack is a useful "oreo" for my needs right now. I understand if "oreo" isn't your cookie of choice. > at the very least I think we can agree that "Doing one thing well" in UNIX means not creating a bunch of new problems that you need other tools to solve. Again, I think the problem here is that we are disagreeing on what the problems even are. Again, I don't think these tools "create problems", I believe they solve very specific problems, and yes very "unix" in that way of solving as specific a problem as they can and no larger, and leave other problems that already existed untouched, whether or not they were in play, because again that's the philosophy here. React is "just" a view layer with a bare modicum of state responsibility. Redux is "just" a state layer. Redux-observable is "just" a tool for handling state side-effects. They don't need to solve every development problem, this isn't Angular. Similarly, they aren't the only tools for the job. There are several alternatives to each part of that stack (as others in this thread keep pointing out), this is just the one I've chosen for my projects right now.
    - rachkovsky 8y ago
      What "state side-effects" are you dealing with?
      - WorldMaker 8y ago
        The obvious and most common is asynchronous state that has some associated loading process/time. Especially those situations where loading some top level object implies to start loading a collection of lower level objects. Reacting to object changes (persisting them to a database, or otherwise audit logging them). Kicking off and managing "background tasks" like chron-job equivalents (5 minutes after a state update do some other related thing, such as a automatic state machine transitions), database synchronization/replication processes, cross-checking/merging in data from GPS/geolocation/compass streams, etc.
- machiaweliczny 8y ago
  Have you tried MobX? If yes - could you share your criticism? I liked it more than redux, because you can have have simple class implementation and side effects without much hassle. Also TS support and testing is easy.
  - WorldMaker 8y ago
    I have not tried MobX. It smells a bit too much like Aurelia, and I've been burnt a bit by Aurelia. More generally, too, things that make heavy use of ES2015 Proxies for side effects tend to make me pause, simply by nature of black/gray boxing those side effects, and also making it a little harder to control/throttle them in cases where performance matters more than "magic". (Which is an interesting turn of events, personally, because I really liked Knockout ages ago, but its attempted successors in MobX, Aurelia, and even Vue leave me cold. I think partly because Knockout was so much more verbose and forced/needed a clearer "MVVM" separation simply by how "dumb" it was, whereas Proxies and Descriptors gives too much of an illusion that you are working with "plain" objects that don't need a clear "MVVM" separation until it is sometimes too late to fix a maintainability/tech debt hole.)
- chrisco255 8y ago
  Plenty of people pair RxJS with React, including PayPal and Netflix. There is nothing precluding you from doing so. What kind of point is this?
  - WorldMaker 8y ago
    Netflix is one of the contributors to redux-observable as well. Sure, you don't need Redux in the middle of the "oreo", but it's also not the "wrong" answer, either.
pault 8y ago
The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. By moving your business logic into your state management framework and using something like redux-saga that is designed specifically for managing complex asynchronous workflows, you can extract your application code from your views and make your views pure functions of the state tree. When I hear someone complaining about redux using global state, I like to ask them what makes global state bad. The answer is usually that it allows any part of the application to change a value, which makes debugging difficult. This doesn't apply to redux and similar frameworks because every slice of the state can only be managed by a single, pure function, which makes it incredibly easy to debug. Additionally, redux uses a copy on write mechanism, so your state tree isn't actually being mutated, which allows you to use equality comparison instead of a deep compare to see what state has changed. That, combined with the fact that all actions go through a central dispatcher that is easily audited means unit testing your state transitions is almost laughably trivial. And since you are pulling all of your business logic out of your UI components, you can avoid the side-effect hell of unit testing your UI. Having said that, I won't use react or redux for any website that doesn't have a heavily interactive UI with complex state that must be shared across many pages. Managing application state in your front end is an enormous burden and you'd be crazy to take it on without a need for it.
- kokokokoko 8y ago
  > The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. I respectfully disagree here. All UI views in React can be controlled via parameters. Very few components in a React application require state management. You can add parameter functions to handle various events as well. > which allows you to use equality comparison instead of a deep compare to see what state has changed You are doing a lot of deep compares on state in a real world application? Why? If you only use parameters for the state of your component, everything is already handled by React out of the box. > every slice of the state can only be managed by a single, pure function Really? You can trigger reducers from literally anywhere in your application. Not only that, you can create multiple reducers to handle each action type. I've seen a situation with 24(yup, 24) reducer functions for a single action type. Many of those reducers contained complex business logic checking the overall state of the application. Then you have 2 or 3 action functions all with different business logic for that one type. Race conditions everywhere. setTimeout 0, here we go again. Step debugger hell. Of course, you should never do this, but in the real world, this is what happens over and over again. > means unit testing your state transitions is almost laughably trivial If you use parameters for state of a component it is 1,000 times easier. Because a component's view is not coupled to the global state of your application. Pass it parameters, test that it looks correct. Change a parameter, check if it is correct. Dead simple. Your tests are not bound to global state at all. Again, you started with an anti-pattern of managing state in child components, and now, instead of not doing the anti-pattern, you are adding yet another tool to fix it. Instead of just not doing it. In summary, what you are describing is the "theory" of why Redux and associated tools should work. In every case that I've seen(10+ at this point) that has not happened. Not because Redux is a bad tool. Its not. But in the real world, it has become incredibly expensive for many organizations to maintain.

WorldMaker 8y ago

Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux itself is just the "stuff inside the oreo" gluing React to all my interesting "epics" describing high level functionality in the applications. It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well.

kerkeslager 8y ago
> From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux itself is just the "stuff inside the oreo" gluing React to all my interesting "epics" describing high level functionality in the applications. The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS. > It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well. Don't sully UNIX philosophy by comparing it to Redux! UNIX is such a different environment from JS space that it's hard to really even compare the two, but at the very least I think we can agree that "Doing one thing well" in UNIX means not creating a bunch of new problems that you need other tools to solve. [1] https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8 https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...
- WorldMaker 8y ago
  > The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS. Yes, and before I was using React+Redux+Redux-Observable I was using Cycle.JS and everything was RxJS and/or Xstream (an RxJS-like) observable-based patterns. As I said, this stack is a useful "oreo" for my needs right now. I understand if "oreo" isn't your cookie of choice. > at the very least I think we can agree that "Doing one thing well" in UNIX means not creating a bunch of new problems that you need other tools to solve. Again, I think the problem here is that we are disagreeing on what the problems even are. Again, I don't think these tools "create problems", I believe they solve very specific problems, and yes very "unix" in that way of solving as specific a problem as they can and no larger, and leave other problems that already existed untouched, whether or not they were in play, because again that's the philosophy here. React is "just" a view layer with a bare modicum of state responsibility. Redux is "just" a state layer. Redux-observable is "just" a tool for handling state side-effects. They don't need to solve every development problem, this isn't Angular. Similarly, they aren't the only tools for the job. There are several alternatives to each part of that stack (as others in this thread keep pointing out), this is just the one I've chosen for my projects right now.
  - rachkovsky 8y ago
    What "state side-effects" are you dealing with?
    - WorldMaker 8y ago
      The obvious and most common is asynchronous state that has some associated loading process/time. Especially those situations where loading some top level object implies to start loading a collection of lower level objects. Reacting to object changes (persisting them to a database, or otherwise audit logging them). Kicking off and managing "background tasks" like chron-job equivalents (5 minutes after a state update do some other related thing, such as a automatic state machine transitions), database synchronization/replication processes, cross-checking/merging in data from GPS/geolocation/compass streams, etc.
machiaweliczny 8y ago
Have you tried MobX? If yes - could you share your criticism? I liked it more than redux, because you can have have simple class implementation and side effects without much hassle. Also TS support and testing is easy.
- WorldMaker 8y ago
  I have not tried MobX. It smells a bit too much like Aurelia, and I've been burnt a bit by Aurelia. More generally, too, things that make heavy use of ES2015 Proxies for side effects tend to make me pause, simply by nature of black/gray boxing those side effects, and also making it a little harder to control/throttle them in cases where performance matters more than "magic". (Which is an interesting turn of events, personally, because I really liked Knockout ages ago, but its attempted successors in MobX, Aurelia, and even Vue leave me cold. I think partly because Knockout was so much more verbose and forced/needed a clearer "MVVM" separation simply by how "dumb" it was, whereas Proxies and Descriptors gives too much of an illusion that you are working with "plain" objects that don't need a clear "MVVM" separation until it is sometimes too late to fix a maintainability/tech debt hole.)
chrisco255 8y ago
Plenty of people pair RxJS with React, including PayPal and Netflix. There is nothing precluding you from doing so. What kind of point is this?
- WorldMaker 8y ago
  Netflix is one of the contributors to redux-observable as well. Sure, you don't need Redux in the middle of the "oreo", but it's also not the "wrong" answer, either.

pault 8y ago

The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. By moving your business logic into your state management framework and using something like redux-saga that is designed specifically for managing complex asynchronous workflows, you can extract your application code from your views and make your views pure functions of the state tree. When I hear someone complaining about redux using global state, I like to ask them what makes global state bad. The answer is usually that it allows any part of the application to change a value, which makes debugging difficult. This doesn't apply to redux and similar frameworks because every slice of the state can only be managed by a single, pure function, which makes it incredibly easy to debug. Additionally, redux uses a copy on write mechanism, so your state tree isn't actually being mutated, which allows you to use equality comparison instead of a deep compare to see what state has changed. That, combined with the fact that all actions go through a central dispatcher that is easily audited means unit testing your state transitions is almost laughably trivial. And since you are pulling all of your business logic out of your UI components, you can avoid the side-effect hell of unit testing your UI. Having said that, I won't use react or redux for any website that doesn't have a heavily interactive UI with complex state that must be shared across many pages. Managing application state in your front end is an enormous burden and you'd be crazy to take it on without a need for it.

kokokokoko 8y ago
> The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. I respectfully disagree here. All UI views in React can be controlled via parameters. Very few components in a React application require state management. You can add parameter functions to handle various events as well. > which allows you to use equality comparison instead of a deep compare to see what state has changed You are doing a lot of deep compares on state in a real world application? Why? If you only use parameters for the state of your component, everything is already handled by React out of the box. > every slice of the state can only be managed by a single, pure function Really? You can trigger reducers from literally anywhere in your application. Not only that, you can create multiple reducers to handle each action type. I've seen a situation with 24(yup, 24) reducer functions for a single action type. Many of those reducers contained complex business logic checking the overall state of the application. Then you have 2 or 3 action functions all with different business logic for that one type. Race conditions everywhere. setTimeout 0, here we go again. Step debugger hell. Of course, you should never do this, but in the real world, this is what happens over and over again. > means unit testing your state transitions is almost laughably trivial If you use parameters for state of a component it is 1,000 times easier. Because a component's view is not coupled to the global state of your application. Pass it parameters, test that it looks correct. Change a parameter, check if it is correct. Dead simple. Your tests are not bound to global state at all. Again, you started with an anti-pattern of managing state in child components, and now, instead of not doing the anti-pattern, you are adding yet another tool to fix it. Instead of just not doing it. In summary, what you are describing is the "theory" of why Redux and associated tools should work. In every case that I've seen(10+ at this point) that has not happened. Not because Redux is a bad tool. Its not. But in the real world, it has become incredibly expensive for many organizations to maintain.