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 ...