Show HN: Build your first real world React.js application
academy.plot.ly
academy.plot.ly
My problem is this: I just can't understand why I'd want to manipulate state in an unsightly switch statement like this one from Chapter 4 of the original post:
switch (action.type) {
case 'CHANGE_LOCATION':
return Object.assign({}, state, {
location: action.location
});
case 'SET_SELECTED_TEMP':
return Object.assign({}, state, {
selected: {
temp: action.temp,
date: state.selected.date
}
});
case 'SET_SELECTED_DATE':
return Object.assign({}, state, {
selected: {
date: action.date,
temp: state.selected.temp
}
});
default:
return state;
}
What's the point with dispatching these fragile "stringly-typed" selectors, when you can just have real functions doing setState() updates on the relevant component?
I'm not trying to be snarky -- I know I'm missing something major here.
On the other hand, you have all the state logic on reducers... If actions were to dispatch state-modifying functions, it wouldn't take long for the code to become really confusing.
The point is that there are a finite, well-enumerated set of possible state changes, which are all localized in one place: the reducer. Whether you call them "DO_THING" vs. constants.actions.DO_THING (which could be an integer or whatever you want) or whether you use a switch statement vs. if block vs. dictionary lookup is entirely up to you.
If you're using a JS typechecker like Flow (and IMO if you're building a large app, you should) you can even make use of disjoint unions to type your Flux action objects: https://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
Using Redux, all or almost all of your state is stored in a global repository (the "store").
Those strings should probably be constants instead, especially for IDE auto-complete purpose, but you are never generating those manually.
Instead, your components would call "action creators", who are properly named functions, which in turn will dispatch one or several actions to the store.
In your component:
actions.changeLocation(someLocation)
changeLocation(location) {
dispatch({
type: CONSTANTS.CHANGE_LOCATION,
payload: { location },
});
} function requestFoos() {
return { type: REQ_FOOS }
}
function gotFoos(foos) {
return { type: GOT_FOOS, foos }
}
export function getFoos() {
return function(dispatch) {
dispatch(requestFoos());
myFooProvider
.getFoos()
.then(function(foos) { dispatch(gotFoos(foos)); });
}
}
We have migrated a load of model logic from Angular to redux and redux saga, once you get your head around a nice structure then its a dream.
I created a gist for you to check out [1]. Maybe also check out the concept of Redux Ducks [2]. I now find our code easy to read, share and test - unlike our massive Angular app.
Also as somebody else comments, you should make sure the only way you talk to your store is through a reducer dispatcher.
Regarding component states, find some reading on components v containers [3] - we even have 2 separate folders for the different types. Once mastered and implemented, most components are small and again easy to test.
[1] https://gist.github.com/anonymous/a20f603f9922742bd3cea7a08c...
[2] https://github.com/erikras/ducks-modular-redux
[3] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
I guess I'll need to do some more reading on how this works in larger applications with more complex model structures. Thanks for the links!
In some ways it is initially a lot of boilerplate for various state reducers, but after everything is there building really functional features is extremely quick with redux; just from a developer's time point of view.
The real power of reducers is composability. For example, I would almost certainly store the "selected" part of the state in a separate reducer. In my personal experience, reducers rarely respond to more than 3-4 actions.
As for the reason to do this instead of setState -- the whole point is to completely encapsulate state into something that's reproducable, trackable, and removable. Almost all of the components you write should be "dumb" -- that is, they just take properties and render some JSX. Then you have a few "smart" components who know about the state and send the data down to it's "dumb" children. Redux/Flux allows your application to be as stateless as possible, which is where React really shines.
case 'CHANGE_LOCATION':
return {
...state,
location: action.location
}I wrote an answer on SO recently that describes some reasons for using Redux, which I'll paste here:
[quote]
Off the top of my head, a few advantages:
- A lot of the time your app's state tree could be considerably different than the UI tree
- Many components may need to access the same state and display it in different ways
- Hot reloading components will wipe out your existing component tree, including any state stored inside of them. Keeping the state separate from the UI tree allows the UI tree to be swapped out and reloaded with the updated components, while keeping your current development state the same.
And that's before getting to many of the commonly discussed benefits, such as predictable state updates, time travel debugging, improved testability, and centralized logic.
It's certainly true that you can write an entire application using nothing but React's component state (and Dan Abramov himself says that people often jump into Redux too early), but from my perspective Redux is absolutely worth it.
[/quote]
As for the switch statements: many of the patterns for Redux usage boil down to "serializability", which is a big deal because it enables scenarios like time travel debugging, persistence of app state, and more. I wrote some thoughts on that topic yesterday, at https://www.reddit.com/r/reactjs/comments/518qdr/anyone_have... .
FYI, I maintain a big list of links to high-quality tutorials on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . You may want to read through some of the Redux tutorials to get a better grasp on how it works and how the pieces fit together.
Looking at that code block I know immediately that there are only 3 ways that the state can change and what happens during each transition.
This code is easy to unit test and verify that it is correct meaning that as long as the frontend components dispatch the right actions the store will contain the correct state.
Since the UI should just be a function of the store this means that there is no guess work when it comes to reasoning about what the rendered view will look like after each action.
I'm working on porting an angular SPA to react/redux. While the amount of code increased the whole thing is a lot easier to understand. The angular version had a lot of race conditions that I could never fix.
For example, something like selection typically isn't part of the model. (Users don't expect to undo a selection in an editor.) That means components will need to manage that kind of transient state internally, and the whole "UI is just a function" paradigm kind of breaks down.
There's a couple recent articles that cover this topic: https://medium.freecodecamp.com/where-do-i-belong-a-guide-to... and http://jamesknelson.com/5-types-react-application-state/ . The Redux FAQ also discusses this: http://redux.js.org/docs/FAQ.html#organizing-state-only-redu... .
> the whole "UI is just a function" paradigm kind of breaks down.
Not really, it just goes from "UI is a function of the store state" to "UI is a function of the store state AND the component's internal transient state". Since internal state should only be modified by the component itself calling setState, this doesn't really add much complexity - in fact it usually reduces app complexity by obviating the need for a complicated global state structure for storing eg. the open state of every possible dropdown on the page.
Or in other words is that you would you prefer OOP polymorphism dispatch or is just that Javascripts switch case statement is weak?
Part of the problem is Javascript doesn't have ADT aka structural pattern matching which is a far far far more powerful switch-like dispatch. Elm does (maybe TypeScript as well?). But OOP dispatch (and I suppose other polymorphic types besides inheritance) are a valid way as well to do this.
Regardless of serialization/replay-ability, the core of the suggestion is to `import` some constant instead of using raw strings. Symbols have the benefit of forcing an import, whereas a list of constants that reference strings can be "bypassed" by writing the correct string in a random file. In fact, the redux actions documentation uses the following example of this pattern as the first example.
``` // fileA const ADD_TODO = 'ADD_TODO'
//fileB { type: ADD_TODO, text: 'Build my first Redux app' } ```
Your reducer can be whatever you want it to be as long as it does not produce side-effects. I use something like https://65535th.com/move-away/
Additionally, as roughcoder points out elsewhere in thread, using the object spread syntax (available in babel-preset-stage-2 or babel-plugin-transform-object-rest-spread) minimizes some additional boilerplate.
As someone approaching web front end development from a clean slate (es6 isn't the monster I though javascript to be, though there are some warts), can you tell me what vue does better than the alternatives (e.g., react)?
I'm building my first prototype of a web-based application right now, and sticking with raw ES6 to keep the cognitive load down (relative to javascript + a framework), but I'm likely to switch to one framework or another to get ride of some of the boilerplate I see happening.
In such a simple example, I think jquery wins. However, more complicated solutions might be better suited towards frameworks like Angular and React.
Which for any new tool is important. Good luck.