fritzpassow

// I think "accumulated" is a better name than "accumulator". // This arg is the value that's been accumulated, not a // long-lasting a thing that accumulates stuff. let arr = [11,22,33] arr.reduce((accumulated, current)=>(accumulated + current)) >>66 // The first call to your function uses the first AND SECOND array elements arr.reduce((accumulated, current)=>{console.log(accumulated + ' ' + current); return 'hi'}) 11 22 hi 33 >>"hi" // ...unless you provide a second arg to Array.reduce itself. If you do, then // that second arg will be passed as accumulated on the first call of your function. // And that also means that the first call no longer consumes two elements. arr.reduce((accumulated, current)=>{console.log(accumulated + ' ' + current); return 'hi'}, 1000) 1000 11 hi 22 hi 33 >>"hi" // Using the second arg is safer. Without it, and empty array does this: ar...

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/Basic_Concepts_of_Grid_Layout Shows how to create your first grid with almost no code. And then introduces syntax in logical steps. Better than what I found Googling for "tutorials". Those might be good for learning how to do specific things or digging into various topics. But if you've never looked at CSS grid and have three minutes to spare, go to the link above.

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} />