The existing Redux "Basics/Advanced" tutorial sequence desperately needs to be rewritten. While it's been useful for many people, the target audience of the Redux docs has changed considerably since Dan first put it together. At the time, Dan said:
So hard to write the new docs. Many different audiences to cater to.
Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too
Flux people: "is this proper Flux?" FP people: "is this that weird thing called Flux?" Normal people: "why not Backbone"
Clearly, the audience today is very different.
The existing tutorial teaches Redux using a "bottom-up" approach, explaining how each piece works individually, and building up towards putting them together into something useful. The new "Redux Essentials" tutorial that I just wrote teaches Redux "top-down", explaining "how to use it the right way", but not covering how it works. Both approaches are needed.
connect as the main React-Redux APIconst ADD_TODO = "ADD_TODO", having separate folders for /actions and /reducers, etc. We now recommend _against_ those approaches, so we need to stop teaching them.My main goals here are:
{type: "todos/addTodo"} vs const ADD_TODO = "ADD_TODO", single-file Redux logic)I'll need to figure out how to balance teaching the individual concepts, with having a coherent set of examples and explanations.
/basics - should be /tutorials/somethingconst ADD_TODO = 'ADD_TODO'type property that indicates the type of action being performed"payload moreindex instead of the whole todo", but rephrase this somehowdispatch and none of that's been mentioned yetnormalizr instead of our own docs pageObject.assign({}, state, arg): ew!Object.assign() warning (ES6? really?)immutability-helper, updeep, and Immutable.jscombineReducers / imports / reducer naming are a bit confusingtodoApp without defining ittodoAppReducer or somethingcombineReducers exampledeku libconnect"TodoList pass down click handlers, and letting Todo dispatch its own actions?This section should not at all be called "advanced". This is pretty key info, and the only real distinction here is that it's stuff that goes beyond using Redux synchronously by itself. Consider renaming it to something else.
error flag, even despite FSA. Drop that.redux-actionsaction.payload, etcreceivePosts() converts json.data.children.map(). Good idea, or bad idea?Object.assigninvalidateSubredditasync/await ?applyMiddlewarestore to storeAPIEverything looks awesome, just have some feedback on the action naming part.
I don't think teaching that inline action names is a good idea. Sure, it makes tutorials simpler and reduces the boilerplate shock effect, but I've seen a lot of newbies and even intermediate devs stick to what they've seen in tutorials as best practice and reject everything else. For example, back when Redux started, I'd suggest if..else or function lookup tables for some reducers and they'd be like "Nooo, never do that, Dan Abramov only uses switch. It's the best practice!".
ADD_TODO or todos/addTodo sounds too imperative. The most common mistake I see these days is imperative set/clear/reset/toggle/update/delete/add style actions which don't describe what happened and instead describe how we want to update the store. Something like TODO_ITEM_ADDED or todos/itemAdded would better underline the fact that actions describe what happened.
Maybe suggest redux-toolkit or a similar library-less way of having generic factories for three-phase thunks. It is in advanced section after all. Instead of suggesting
{ type: 'FETCH_POSTS_REQUEST' }
{ type: 'FETCH_POSTS_FAILURE', error: 'Oops' }
{ type: 'FETCH_POSTS_SUCCESS', response: { ... } }
could have an example of a simple thunk creator function that's passed FETCH_POSTS and implicitly generates the above three action types.
@MilosRasic yeah, I'm inclined to go with 'todos/todoAdded' as well.
The point of the inline action names is to remove the extra line of code needed for the old classic const ADD_TODO = "ADD_TODO" pattern. I'm going to have to find a way to emphasize in these docs that "this is how it works underneath, but this isn't how we recommend using it - use RTK instead".
Similarly, the purpose of this tutorial is to show the mechanics and how you _would_ write this code "by hand", so that you later understand what RTK's abstractions do for you. In fact, I think the best way to finish this tutorial would be to migrate all the code we write over to RTK to show how much nicer it is.
Here's my initial thoughts on how to tackle this:
counter-vanilla example, but with an object instead of a single numbersubscribe -> getState -> update UI cycleredux-thunk and store setup(dispatch, getState) => {} func inline and pass directly to dispatch, no dispatch(fetchData()) And this is now LIVE!
Most helpful comment
Basics Tutorial Rewrite Plans
Initial Thoughts
Here's my initial thoughts on how to tackle this:
counter-vanillaexample, but with an object instead of a single numberOutline
Part 1: Redux Overview
Part 2: Redux Terms and Data Flow
Part 3: Actions and Reducers
Part 4: Store
Part 5: UI
subscribe -> getState -> update UIcyclePart 6: Async Logic and Data Flow
redux-thunkand store setup(dispatch, getState) => {}func inline and pass directly todispatch, nodispatch(fetchData())Part 7: Standard Redux Patterns
Part 8: Modern Redux
Part 9: Next Steps