fritzpassow

x = {a:1, b:2, c:3} x.b = undefined console.log(JSON.stringify(x)) > {"a":1,"c":3} //No more "b" !!! //But "b" is still on the object... Object.keys(x) >  ["a", "b", "c"] console.log(x) > {a: 1, b: undefined, c: 3}

I've always agreed that Test Driven Development was a good idea and I should be doing it. But it's hard to do on top of learning new tools. And it's hard to do for GUIs. So it never quite happened. However, after I worked with React and Redux a bit, and after doing a couple hello-world tests with Jest, it all fit together and actually made coding easier and more fun. These were the parts that came together to make it work: Jest: Jest is included with create-react-app and is stupid-easy to start using. The Redux reducer, or functions used in the reducer, have to be pure functions and are therefore stupid-easy to test. I pulled some functions out of Redux Container mapStateToProps. These are also pure functions. I also decided that the outputs from mapStateToProps had to have the same structure, and even use most of the same names, as the container component and all of it's child components. In other words, you could dump the data coming out of mapStateToProps a...

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