fritzpassow

MDN has a very good page on async (and await ) . Having read them the MDN page plus a bunch of other tutorials, here are my key takeaways: In general: async and await are just a nicer syntax for working with promises. So learn promises. Understand promises. And then use async and await to make your promise-using code look nicer. About async : Putting async  in front of a function definition allows you to use await inside that function. Putting async in front of a function definition  also wraps the function's return value in a promise, if the return value wasn't a promise already. So if my function gets data via a promise and then extracts and transforms the data before returning it,  I can just return my transformed data and let async magically re-promise-ify the data for me. :-) About await : await lets me use functions that return promises, but write code that looks synchronous, i.e.the code looks as if the function that returns a promise was an old fa...

The source for combineReducers(...) is really, really short. Take a look:  https://github.com/reduxjs/redux/blob/master/src/combineReducers.js What it does is also simpler than I thought. No complex composition of reducers working on different levels of an object tree, etc. Reducers can ONLY be properties directly on the object you feed to combineReducers(...). And combineReducers(...) can ONLY feed them properties that are directly on the state object. Hmmm... I understand more and more why my state object should be "normalized"

This is legal: <Foo {...object_with_multiple_props} />

render() only returns one element. So we get useless DIVs, like: return (     <div className="useless">         <h1>I wanted this</h1>         <p>I wanted this, too</p>     </div> ) But React now has React.Fragment. import React from 'react' ... return (     <React.Fragment>         <h1>I wanted this</h1>         <p>I wanted this, too</p>     </React.Fragment> ) And when we inspect the result in the browser, we only see the H1 and the P tags. And there's even a shorter bleeding-edge syntax: <> .... </> return (     <>         <h1>I wanted this</h1>         <p>I wanted this, too</p>     </> ) See:  https://reactjs.org/docs...

I read and reread docs and tutorials about "ref", but they never quite connected with my general knowledge of JavaScript. So I did more digging and here's what I found: Ref's are a way to get a reference to an actual HTML DOM node that was generated by React. (They can also get a reference to a React component instance, but I'm not going there today.) React.createRef() just returns a new object like {current:null}. So I assume that's what a ref looks like. From looking at examples... when some element includes an attribute called "ref", like this: <foo ref={expression_that_evaluates_to_a_ref}     /> ...then the JSX is compiled into some JavaScript which assigns a reference to the foo DOM node to the "current" property of that ref object. So we use this by calling React.createRef() and putting a reference to the ref object somewhere where we will be able to get it later.  Then after render() runs and our ref object's ...

I think I understand the pieces now... React Functional Components: Are the preferred kind of component we write in React-Redux Are functions that take a "props" object Are the preferred way to output visual stuff and wire up events The Redux Store: Has all the state which we can display Has the dispatch(action) method, which is the only way to change state Your Mission (should you choose to accept it): Use the state and the dispactch(action) function Create props which are data values needed by the functional component Create props which are event handlers that call dispatch(action) The Locations: mapStateToProps : Here you get the state and return props which are just data mapDispatchToProps : Here you get the dispatch function and return props which call it And then React-Redux's "connect" function magically combines the mapping functions and your functional component into a new component which you elsewhere. ---------------------...

With just callbacks or promises, one can almost read the code as non-functional, with a few extra parens 'n things thrown in. If you ignore the yellow parts below, it could almost be C or Java. whatever.then (()=> {       code       code       code } ) "then"... the code in curly braces happens. But in Redux, we get things like this fragment from  https://github.com/reduxjs/redux/blob/master/examples/todos/src/containers/VisibleTodoList.js const mapDispatchToProps = dispatch => ({   toggleTodo: id => dispatch(toggleTodo(id)) }) export default connect(   mapStateToProps,   mapDispatchToProps )(TodoList) Here,  mapDispatchToProps is a function which takes a function ( dispatch ) as its argument and returns an object who's property's value is also a function. Then  mapDispatchToProps  i s used as an argument to the connect(..) function which returns a function whose argument ...