6 ms·

Maybe I'm missing something, but isn't the appeal of the React/Redux stack that it is simple? Does one really need to read dozens of articles as a starting poi

by lhorie 11y ago

Maybe I'm missing something, but isn't the appeal of the React/Redux stack that it is simple? Does one really need to read dozens of articles as a starting point to get into this stack? Or is the learning curve to the latest and greatest patterns actually significant? (Note: I'm not trying to shoot this down, I'm legitimately curious about the perspective of those who are starting to learn)

dcwca 11y ago
It keeps simplicity low for large and complex projects, but isn't simple to get started with.
- mooseburger 11y ago
  You mean complexity low, not simplicity low, yes?
acemarke 11y ago
There's varying aspects of complexity involved: * Both React and Redux have very small API surfaces, but do involve very different ways of thinking for someone coming from a jQuery or Backbone background * While the "Javascript Fatigue" argument is a bit worn out by now, there _is_ validity in the point that there can be lots of moving pieces to set up * There are some significant nuances with both libraries once you get past the "Hello World" stage. State shape, performance optimization, managing more complex use cases, etc. Beyond that, there's a _lot_ of articles and tutorials out there, and the quality of the information varies considerably. I did a lot of bookmarking while I was learning these things last year, and have found myself answering many of the same questions over and over on Reddit and Reactiflux. I wanted to put together a consolidated reference of good information that I could point people to. So no, you probably don't need to read "dozens" of articles to get started, but one person might find a certain 3 or 4 articles more useful than someone else (kind of along the lines of how "everyone uses 20% of MS Word's features... but everyone uses a different 20%").
switz 11y ago
No matter how simple a piece of technology is at face value, people often use its simplicity to solve complex problems. Sure, building a TODO list with react and redux is easy enough, but once you start building a large or complex application you need to establish patterns and design decisions in order to scale the codebase well. I can't speak to the quality of this list, but I gather that, rather than a defacto list of how to go from 0 to expert on react and redux, the author intended to curate a list of tutorials that they found insightful so you don't have to go digging around Google.
- acemarke 11y ago
  Exactly. It's specifically intended to be tutorials and information that I have evaluated and determined to be well-written and informative, so that it's a one-stop set of resources for someone wanting to learn.
interlocutor 11y ago
So what problem does Redux solve? From its doc: "It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test." Sorry, I am not sold. Can anyone summarize what problem it solves in a short paragraph?
- acemarke 11y ago
  It's state storage. If you've got any familiarity with Backbone, all of your Models and Collections define the current set of data for your application. You may also have a lot of UI-related state, like which tab is selected, which pane is open, etc. Redux lets you put all that information into one place (although how much or how little of your state goes in there is up to you). It also defines certain conventions around updating that data. In Backbone, anyone with a reference to a Model can call myModel.set("someField", someValue) at any time. In Redux, "write" logic is isolated to a user-defined set of "reducer functions", which only respond to specific types of messages. This makes it _very_ easy to determine when and why a particular bit of data changed. In addition, it enables scenarios such as storing the entire list of dispatched actions, and then playing back each action step-by-step to allow you to see how you got to a given state in your application (aka "time-travel debugging").
- delluminatus 11y ago
  Redux tries to enforce a convention that all application state is stored in a single object (the "store") and modified using a single pure function (the "reducer"). These conventions make it easier to reason about the application's current state. Applications behave consistently because all state is stored in a single object, so it can't be desynchronized across components. Because all updates use a single function, it becomes easy to track and respond to any state changes by applying middlewares to that function. Things are more testable because all state is available for stubbing, and because the "reducer" is a testable, pure function typically composed of many other smaller, testable pure functions. Things like time travel become possible because of the purity of the reducing function. Since it's pure, it can't modify the old state object (technically, it can, but it's against the rules). So in theory, we can undo any state change simply by loading the old state object from where it's being stored by some kind of history middleware.
d0m 11y ago
The surface area of react and redux is small and simple, but that doesn't mean that building complex applications with it is easy. Essentially, redux is just a big reduce on an immutable object. The just here is what makes redux great and open many possibilities with the time travel, etc. That being said, I'm still trying to figure out how to build a few parts of my app the "Redux" way and I feel like it's making it way more complex instead of simplifying it. For instance, in most redux trivial examples, the store and the views are directly mapped. I.e. 4 tasks in the store = 4 tasks on the screen. But in practice, sometimes the view evolves differently. Maybe we don't want to show the new task because it would confuse the user and it would be better instead to show a "Show new changes" button. But then, you're now duplicating the state of the app. Since redux only tells you when the AppState has changed, how do you figure out how to update that UIView strictly from the AppState()? Yes, you can regenerate UIState every time but you need to store additional stuff in the AppState to be able to do that (For instance, was the "Show Change" button shown or not?). Also, regenerating a very big object on every change in the store can truly degrade performances. There are some libraries (Such as reselect), but it's essentially the same thing, your view object needs to be recreated from scratch when there's a relevant change in the AppState. One possible solution is to have components listen to the store actions and they would have their own reducer to update the "UIState" accordingly. But then it's moving away from the current "Redux Way". That's just one example of how it can get complex even though the redux idea (One store, one reducer) is simple. By the way, anyone knows how to solve the issue I just mentioned? :)
- acgourley 11y ago
  This performance tip seems relevant to you: https://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate https://facebook.github.io/react/docs/component-specs.html#u...
  - d0m 11y ago
    I'm already using immutable objects, this is a separate issue. The question is about how to keep the UIState (Say inside a component) in sync with the AppState considering they both evolve differently?

by lhorie 11y ago

dcwca 11y ago

It keeps simplicity low for large and complex projects, but isn't simple to get started with.

mooseburger 11y ago
You mean complexity low, not simplicity low, yes?

acemarke 11y ago

There's varying aspects of complexity involved: * Both React and Redux have very small API surfaces, but do involve very different ways of thinking for someone coming from a jQuery or Backbone background * While the "Javascript Fatigue" argument is a bit worn out by now, there _is_ validity in the point that there can be lots of moving pieces to set up * There are some significant nuances with both libraries once you get past the "Hello World" stage. State shape, performance optimization, managing more complex use cases, etc. Beyond that, there's a _lot_ of articles and tutorials out there, and the quality of the information varies considerably. I did a lot of bookmarking while I was learning these things last year, and have found myself answering many of the same questions over and over on Reddit and Reactiflux. I wanted to put together a consolidated reference of good information that I could point people to. So no, you probably don't need to read "dozens" of articles to get started, but one person might find a certain 3 or 4 articles more useful than someone else (kind of along the lines of how "everyone uses 20% of MS Word's features... but everyone uses a different 20%").

switz 11y ago

No matter how simple a piece of technology is at face value, people often use its simplicity to solve complex problems. Sure, building a TODO list with react and redux is easy enough, but once you start building a large or complex application you need to establish patterns and design decisions in order to scale the codebase well. I can't speak to the quality of this list, but I gather that, rather than a defacto list of how to go from 0 to expert on react and redux, the author intended to curate a list of tutorials that they found insightful so you don't have to go digging around Google.

acemarke 11y ago
Exactly. It's specifically intended to be tutorials and information that I have evaluated and determined to be well-written and informative, so that it's a one-stop set of resources for someone wanting to learn.

interlocutor 11y ago

So what problem does Redux solve? From its doc: "It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test." Sorry, I am not sold. Can anyone summarize what problem it solves in a short paragraph?

acemarke 11y ago
It's state storage. If you've got any familiarity with Backbone, all of your Models and Collections define the current set of data for your application. You may also have a lot of UI-related state, like which tab is selected, which pane is open, etc. Redux lets you put all that information into one place (although how much or how little of your state goes in there is up to you). It also defines certain conventions around updating that data. In Backbone, anyone with a reference to a Model can call myModel.set("someField", someValue) at any time. In Redux, "write" logic is isolated to a user-defined set of "reducer functions", which only respond to specific types of messages. This makes it _very_ easy to determine when and why a particular bit of data changed. In addition, it enables scenarios such as storing the entire list of dispatched actions, and then playing back each action step-by-step to allow you to see how you got to a given state in your application (aka "time-travel debugging").
delluminatus 11y ago
Redux tries to enforce a convention that all application state is stored in a single object (the "store") and modified using a single pure function (the "reducer"). These conventions make it easier to reason about the application's current state. Applications behave consistently because all state is stored in a single object, so it can't be desynchronized across components. Because all updates use a single function, it becomes easy to track and respond to any state changes by applying middlewares to that function. Things are more testable because all state is available for stubbing, and because the "reducer" is a testable, pure function typically composed of many other smaller, testable pure functions. Things like time travel become possible because of the purity of the reducing function. Since it's pure, it can't modify the old state object (technically, it can, but it's against the rules). So in theory, we can undo any state change simply by loading the old state object from where it's being stored by some kind of history middleware.

d0m 11y ago

The surface area of react and redux is small and simple, but that doesn't mean that building complex applications with it is easy. Essentially, redux is just a big reduce on an immutable object. The just here is what makes redux great and open many possibilities with the time travel, etc. That being said, I'm still trying to figure out how to build a few parts of my app the "Redux" way and I feel like it's making it way more complex instead of simplifying it. For instance, in most redux trivial examples, the store and the views are directly mapped. I.e. 4 tasks in the store = 4 tasks on the screen. But in practice, sometimes the view evolves differently. Maybe we don't want to show the new task because it would confuse the user and it would be better instead to show a "Show new changes" button. But then, you're now duplicating the state of the app. Since redux only tells you when the AppState has changed, how do you figure out how to update that UIView strictly from the AppState()? Yes, you can regenerate UIState every time but you need to store additional stuff in the AppState to be able to do that (For instance, was the "Show Change" button shown or not?). Also, regenerating a very big object on every change in the store can truly degrade performances. There are some libraries (Such as reselect), but it's essentially the same thing, your view object needs to be recreated from scratch when there's a relevant change in the AppState. One possible solution is to have components listen to the store actions and they would have their own reducer to update the "UIState" accordingly. But then it's moving away from the current "Redux Way". That's just one example of how it can get complex even though the redux idea (One store, one reducer) is simple. By the way, anyone knows how to solve the issue I just mentioned? :)

acgourley 11y ago
This performance tip seems relevant to you: https://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate https://facebook.github.io/react/docs/component-specs.html#u...
- d0m 11y ago
  I'm already using immutable objects, this is a separate issue. The question is about how to keep the UIState (Say inside a component) in sync with the AppState considering they both evolve differently?