JavaScript and React.js

I love using the spread operator to clean up my prop passing when working with React, which I always placed in my render . I love using the spread operator to clean up prop passing when working with React, which I always placed in render . render() { const componentProps = {dog: 'dog', cat: 'cat'} return ( &ltdiv&gt &ltMyComponent {...componentProps}/&gt &lt/div&gt ) } One level of abstraction for prop passing. But we can go deeper. One more level of abstraction. > Why I found myself writing a component with 7 children, all of which needed props (will probably need refactoring later on). I was declaring my props, as normal, in my render . But it ended up being 30 lines of code before I even returned anything. I have a solution Make an entirely new function and create all your props there. get childComponentProps() { const componentProps = {dog: 'dog', cat: 'cat'} return ...

You should always be as expressive as possible with your code. That usually means you will sometimes sacrifice wordiness with brevity. But sometimes you can get have the best of both worlds. Luckily, ES6 gives you a lot of tools to do just that. Object destructure func arguments Now we're getting a little fancy. But it's another great way to shorten code. const nestedSubarrays = [[1,2], [3,4]] for (let [i, j] of nestedSubarrays) { console.log(i); console.log(j) } Object destructuring can get really really fancy. const nestedSubarrays = [[1,2], [3,4], [5, 5], [6, 3]] const sortedBySecondEl = nestedSubarrays.sort(([a1, b1], [a2, b2]) => { return b1 - b2 }) Arrow functions can be one-liners The beauty of compact and verbose code. Note that one-liners are denoted using parenthesis, not curly braces. The parenthesis allow implicit return, as opposed to JavaScripts normal explicit return const arrowF...

Comments usually help you, but they can lie. Sometimes that lie will lead you down a wild goose chase to find something that doesn't exist. The JavaScript engine cannot validate comments so they have to always be taken at face value. Use them only when you need to. Luckily, ES6 brings some nice features to cleanly avoid comments when passing props into components. Let's look at a small example. Not all of data in our ParentComponent gets passed into UserProfile, its child component. But at the same time, we want to make our code as readable and expressive as possible. There are multiple ways to approach this. import React, { Component } from 'react' // ParentComponent props // this.props = { // name: 'Andrew', // description: 'A person', // imageUrl: 'http://www.somewebsite.com/profile_picture.jpg', // age: 26, // height: '180cm', // birthday: '10.18.1990', // favoriteColor: 'blue', //...

JavaScript's use of equality is, objectively, counterintuitive. But there is some method to the madness. In its own way, it makes sense (mostly). But it can not be inferred. You have to learn it. Type coercion with == The thing that everyone hates. So what is type coercion? Type coercion is what happens when you ask JavaScript to compare something that is sort-of-kind-of might be true. The list of rules are massive. Numbers can turn into strings; null turns into 0; booleans convert to numbers; This monstrosity of "logic" with null and 0. You can sit down and learn all of the rules if you hate yourself. But the more convenient option is to just never use == Strict equality with === This is equality with zero type coercion. Much better. JavaScript's strict equality properly compares primitives For primitives, comparisons are very straightforward. They are compared by its value, because ...

An unintuitive concept, but these are fundamentally different &ltbutton onClick={this.runFunction}//&gt //NOT THE SAME &ltbutton onClick={() => this.runFunction()}//&gt Try it out yourself later in a component, where this.runFunction uses this.setState . The first will throw an error. The other will not. Theres a short explanation and a long one. To someone who has no idea why these two are different, I think a long explanation is in order. function and its this play by its own rules The defintion of context in a function does not obey lexical scoping unless you tell it to. If you give it no declarations, it assumes this is the window object. Strict declaration of context this.myFunction // 'this' is my context, where my 'this' resulting declaration will obey lexical scoping function ConstructorExample() { this.testAnonThis = function() { //this.testThis binds this function to my constructor's cont...

I was having trouble making image rendering tidy and clean in a project I'm currently brushing up on. I solved it using a component as a wrapper that controls render based on whether or not all images were loaded inside the wrapper's children. I couldn't find any solutions online so I published it to npm. Its name is react-on-images-loaded. Check out my demo and see how you like it. It's a more versatile version of my original solution. It's okay if you hate it and uninstall. You might run into problems as well. If either of those happen, kindly take the time to tell me what's happening or send me the hateful message here ! :) It was shocking easy to make my own package In the same way create-react-app makes setting up a React.js app a breeze, generator-react-component exists for anyone looking to publish their own npm package. Note that you hav...

Symbols  were quietly added to ES6. As a web developer, they have low use cases. But Symbol.iterator , embedded into certain object types, give developers access to ES6s new iterator. The for...of  loop This new loop is similar to .forEach  for arrays, but the main difference is that for...of loops can be used on anything with a Symbol.iterator attribute. for (let char of "console.logged character by character") { console.log(char); } new String()[Symbol.iterator] ? true : false // true new Array()[Symbol.iterator] ? true : false // true new Set()[Symbol.iterator] ? true : false // true new Map()[Symbol.iterator] ? true : false // true This means strings, maps , sets , and arrays are all iteratable using for...of loops. Array.from for objects that have a Symbol.iterator Array.from is essentially a "mapped" version of what a for...of loop does. Array.from("string") //['s', 't', 'r', 'i', 'n', 'g...