Closed markerikson closed 3 years ago
Everything 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!
Overview
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:
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.
Flaws with the Tutorial
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.Goals
My main goals here are:
{type: "todos/addTodo"}
vsconst 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.
Existing Redux Tutorial Sequence Notes
Previous Personal Notes
Feedback
Introduction
Basics
/basics
- should be/tutorials/something
Actions
const 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 yetReducers
normalizr
instead of our own docs pageObject.assign({}, state, arg)
: ew!Object.assign()
warning (ES6? really?)immutability-helper
,updeep
, andImmutable.js
combineReducers
/ imports / reducer naming are a bit confusingStore
Data Flow
todoApp
without defining ittodoAppReducer
or somethingcombineReducers
exampleUsage with React
deku
libconnect
"TodoList
pass down click handlers, and lettingTodo
dispatch its own actions?Advanced
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.
Async Actions
error
flag, even despite FSA. Drop that.redux-actions
action.payload
, etcreceivePosts()
convertsjson.data.children.map()
. Good idea, or bad idea?Object.assign
invalidateSubreddit
async/await
?Async Flow
Middleware
applyMiddleware
store
tostoreAPI
Usage with React Router
Example: Reddit API
Next Steps