• Create React App
• React Dev Tools
• Storybook
• React Style guide generator
• Material UI

Create React App

Easiest way to get started with React. It comes in bundled with everything you need to start a React project without doing all the configuration grunt work.

Follow the steps from here.

React Dev Tools

This is a must have for debugging React. React dev tools allows you to traverse your components, look at their props and states in real time, give performance suggestions etc.

To learn more, visit their blog.

Storybook

Storybook is a UI development environment for React components. It lets you develop and test React components interactively and you can also build your own component library. With Storybook, you can view the different states of each component and develop it in isolation from your app.

React Style guide generator

As the name suggests, you can use React Style Guide Generator tool to create a style guide for your app which will enforce consistency and reuse throughout your app.

Material UI

React Material UI is my favorite front end component library. Its modern, sleek and intuitive.

• Container and View components a.k.a. Smart and Dumb components
• Higher Order Components
• Controlled Components
• A component should be an self contained module
• Create a wrapper 3rd party components
• Use propTypes and defaultProps
• When updating state, always use prevState

Container and View components a.k.a. Smart and Dumb components

This by far my favorite React pattern and enforces the divine coding rule of single responsibility. The idea is simple: encapsulate your logic i.e. business logic or fetching data into a component (container or smart components) and your presentation logic into another component (view or dumb component) who’s only responsibility is to take data and render html. The container component will do all the heavy lifting and render the view component passing in the required data.

Learn more from the man himself: smart vs dumb components.

Higher Order Components

The name higher order component comes from higher order functions, which takes other functions as arguments. HoC takes in a component as an arg, adds some logic and returns another component with the added logic. The idea is that the ‘added logic’ can be reused agnostically with any other component, thus keeping your code ‘DRY’.

Learn More.

Controlled Components

Controlled components deal with HTML form elements such as , , and . You wrap these elements with a custom component and dictate their behavior, like what happens when a user clicks on a radio button, using the state of the wrapper component. Why you ask? It has something to do getting data from DOM more efficiently. Probably.

Learn More.

A component should be an self contained module

The whole philosophy behind React is that you create reusable and modularized components. This ensures maintainability and consistency throughout the app. I like to keep my component source code, test code and css files in the same dir. It makes it easier to find everything you need for that component. You don’t have to go on a wild hunt. Moreover, it reinforces the idea that your component is the source of reusability. If you want to use your component in a different project, you can just copy that directory and use the component.

Create a wrapper 3rd party components

This helps with consistency throughout your app. Let’s say you are using a third party carousel component. Wrap it in a custom component and add your own modifications. Now when you need to use it again somewhere else, you can just use . You don’t need to add your modifications again.

Use propTypes and defaultProps

One of JS’s curse (or blessing, depending who you ask) is that it’s not type safe. Of course you can use TypeScript, but that’s not a part of this doc. One way you can add a little bit of type safety to your components and make them more robust is by using propTypes.

Use defaultProps which are static class properties of React.Component that the component uses if no props are passed to it.

When updating state, always use prevState

Its very easy to forget that setState is async, and therefore the current state might not be what you think it is. So when you call setState, the safest bet is to use the prevState to update the newer state.

this.setState((prevState) => {
            return { numOfClicks: prevState.numOfClicks + 1 };
});

• Intro
• Basic test (test state and props)
• Testing user interaction
• Testing whether a class method is called or not
• Things to remember

Intro

I am assuming you already have a testing environment set up with all the tools installed: karma + webpack and enzyme.

If not, these are good resources:

• How to test React with Jest & Enzyme
• Using Enzyme with Karma

Basic test (test state and props)

We want to test the Button component defined in our react component guide.

import React from 'react';
import { shallow } from 'enzyme';
import Button from './Button';


function render(props) {
	return shallow();
}

describe("Button component tests", () => {
    it("renders the prop correctly", () => {
        props = {
            buttonName: 'mockButton'
        };

        const renderedComp = render(props);

        expect(renderedComp.props().buttonName).toEqual(props.buttonName);
    });

    it("has correct initial state", () => {
        const renderedComp = render({});
        expect(renderedComp.state().numOfClicks).toEqual(0);
    });
});

Testing user interaction

it("increase numOfClick by 1 when button is clicked", () => {
    const renderedComp = render({});
    expect(renderedComp.state().numOfClicks).toEqual(0);

    const button = renderedComp.find('button');
    button.simulate('click');
    
    expect(renderedComp.state().numOfClicks).toEqual(1);    
});

Always try to mock user interaction as much as possible i.e. simulating a click.

Testing whether a class method is called or not

it("increase numOfClick by 1 when button is clicked", () => {
    const functionToBeCalled = spyOn(Button.prototype, 'handleClick')

    const renderedComp = render({});
    const button = renderedComp.find('button');
    button.simulate('click');
    
    expect(functionToBeCalled).toHaveBeenCalled();    
});

Things to remember

• You can have nested describe blocks. Your describe block should act like a test suite.
• Each it block should test one piece of functionality.
• Use beforeAll() and beforeEach().
• shallow rendering will get the job done 90% of the time. But, there are times when you need to use mount to do a full mounting of your react component in your tests. To learn more about their differences, visit here.

• The hard way – without create-react-app
• The easy way – with create-react-app
• Babel
  • Terms to know
• Webpack
  • Loaders
  • Environment
  • Running webpack

The hard way – without create-react-app

• Create a node project:
  npm init -y
• Install react and react-dom:
  npm install react react-dom
• You will need atleast two files: a js file for your react component and a html file to bootstrap your react components.

// index.js

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';

class App extends React.Component{
    render(){
        return(
            <div>Hello World</div>
        )
    }
}

ReactDOM.render(<App />, document.getElementById('app')); 

// index.html

<!DOCTYPE html>
<html>
    <head><title>
        my-app
    </title></head>
    <body>
        <div id="app"></div>
    </body>
</html>

Code taken from: https://dev.to/vish448/create-react-project-without-create-react-app-3goh

• When the code is built, the js file will be run and ReactDOM.render() will inject React code into index.html.
• We can use webpack to bundle the code and babel to transpile JSX.

The easy way – with create-react-app

• Easiest way to get started with React. Comes with all the tools necessary, including webpack, Babel etc.
• Follow the steps from here.

Babel

Problem: You want to write newer JS i.e. es6 but not all browser can compile and run the newer syntax and features.

Solution: Babel transpiles newer JS into older ones so that it works with all browsers. Babel also allows us to polyfills to use newer functionalities that cannot be transpiled.

Terms to know

• preset: an array of plugins used to support a particular JavaScript language feature.
• @babel/preset-env: a “smart” preset that allows us to use the latest JavaScript without needing to manage which specific syntax transformations or polyfills are needed by your target environments.
• target enviroments: the browsers you want babel to transpile to
• browserlist: Project that lets us specify target environments using queries. Babel recommends putting the queries in a .browserslistrc file.

# Browsers we support

last 2 versions
not dead
> 0.5%

We want to target the last 2 versions of all major browsers that are not dead and has more than 0.5% of market share.

• babel.config.js: Where we put all of our babel config stuff so that we don’t have to run babel through long cli commands.
• polyfills: Certain newer features of JS cannot be converted to older syntax because there is no older equivalent. For those, we define polyfills, which are code added to the browser API. We can use core-js to add polyfills to our app, via @babel/preset-env.

// babel.config.js

const presets = [
  ["@babel/preset-env", { // Pass a config object to the preset
    debug: true, // Output the targets/plugins used when compiling

    // NEW CODE:

    // Configure how @babel/preset-env handles polyfills from core-js.
    // https://babeljs.io/docs/en/babel-preset-env
    useBuiltIns: 'usage',

    // Specify the core-js version. Must match the version in package.json
    corejs: 3,

    // Specify which environments we support/target. (We have chosen to specify
    // targets in .browserslistrc, so there is no need to do it here.)
    // targets: "",

    // END NEW CODE

  }],
];

const plugins = [];

// Export a config object.
module.exports = { presets, plugins };

Code from here

Webpack

Bundles all of your front end resources into one or more modules so that they can consumed in production. Webpack is not restricted to just bundling resources. It minimizes files, transpiles and adds polyfills using babel, preprocesses and compiles css modules like SASS, etc.

We pass an entry file to webpack and from there it traverses all the dependencies (probably recursively) from file to file. That’s how webpack knows which resources it needs to include in the bundle.

Loaders

Loaders are used to tell Webpack how to treat the different modules that we import throughout our app. Using loaders we can tell Webpack what to do when we import sum from ‘./sum’, import ‘./styles/main.scss’ and import logo from ‘./logo.png’. For example, using a loader we can instruct Webpack to run .scss files through a Sass compiler [1].

With that in mind, let’s move the babel config into webpack. Then we don’t need to use babel.config.js anymore.

Environment

Depending on the environment, we might want to do different stuff i.e. output more logs to console in dev mode. Webpack allows us to define the behavior for different envs. All we need to do is return a function instead of an object. If we export a function, it will be passed with two parameters, the first
of which is the webpack command line environment option --env. The other one is --arvgv.

The other option is to define two webpack config files: one for dev and the other for prod.

Running webpack

// package.json
{
  "scripts": {
    "build": "webpack --env.environment=production --config webpack.config.js",
    "dev": "webpack --env.environment=development --config webpack.config.js",
    "devserver": "webpack-dev-server --env.environment=development --config webpack.config.js"
  },
  ...

To learn more, you can visit this page.

• Dissecting the building block of React: A Component
• Defining a component
• Using a component
• Types of component
  • Functional Component
• Component Lifecycle

Dissecting the building block of React: A Component

The whole idea behind React is modularization and reusability. React components are the building blocks of this modularization. The idea is simple: you encapsulate your front end bits in components and then reuse them. Let’s dissect a moderately complex React component:

Defining a component

import React, { Component } from "react";

class Button extends Component {
    constructor(props) {
        super(props);
        this.state = { // [1]
            numOfClicks : 0
        }    
        this.handleClick = this.handleClick.bind(this); // [2]
    }

    handleClick() { // [3]
        // code to handle what happens when the button is clicked

        this.setState((state) => { // [4]
            return { numOfClicks: state.numOfClicks + 1 }; // Update current number of clicks by 1 since someone just clicked it
        });
    }

       render() { // [5]
        let buttonName = this.props.buttonName; // [1]
        return (
            <button onClick={this.handleClick}> // [6]
                {buttonName}
            </button>
        );
    }
}

export default Button; // [7]

1. We pass data to a React component using props. In our example, the parent component of Button i.e. whoever is rendering the component can pass in the button name using the buttonName prop. A component can hold data about itself in state. This is an object that describes the state of the component at that point of time. To learn more about state vs props click here.
2. If we are passing in a function to another component, we have to bind ‘this’ to the function, so that when it gets called, it uses the correct ‘this’ context. For our example, since handleClick will be invoked by html tag, we need to bind the ‘this’ context of our Button class to the function. To learn more, click here.
3. We can define class methods for our own use. This is a good practice since it allows us to test individual bits of code by themselves.
4. Here we are updating the state for the class. Every time the state changes, the component re renders.
5. Render is the only method you have to implement for every React component. This is what gets called when a component is rendered/invoked and in our case, outputs the html.
6. Our Button class ultimately will output this bit of html and paint the DOM with it. We are also rendering the button name from the passed in prop.
7. We have to export our component so that we can use it. Whoever uses it will import this class.

Using a component

import Button from './Button.jsx';

class Header extends Component {
    render() {
        <Button buttonName='Login' />
    }
}

export default Header;

Types of component

The example above is a React class component i.e. you create a class object. The other type of component is called a functional component, where you define the component as a function.

Functional Component

// Style 1
const Header = (props) => (
{props.headerTitle}
); // es6 automatically returns the h1 without the return keyword.

// Style 2

function Header(props) {
    return (
{props.headerTitle}
);
}   

Functional components are a bit more performant, easy to read and test. If you do not need state for your component, then go with functional components. To learn more, click here.

Component Lifecycle

Lifecycle methods are invoked during different life cycle events of a component. If you want your component to execute some logic during different lifecycle events, you can add them to the appropriate lifecycle method.

Fig 1: React Lifecyle. Image taken from reactjs.org

Next: Running React

If you are like me, then chances are good that your React skills and knowledge gets rusty if you are not constantly working with it. If not, kudos to you!

I tend to forget things a lot and therefore have to review them every time I come back. This is the true essence of this project: a condensed yet comprehensive guide to get you up to date with React in the shortest amount of time. Not just the basic React syntax, but all the fluff and gruff that goes with working with React i.e. best practices, testing components, frontend build pipeline etc.

This is designed for people who are familiar with React and front end build tools and just need a refresher. This guide is not detailed and does not aim to be a starter tutorial.

Table of Content

1. React Core
2. Running React
3. Testing React
4. Best Practices
5. Tools

The premise of the paper is simple: they want to know whether, and how, the way information is phrased and structured can affect how much people remember them. This has application ranging from better script writing to advertisement and politics. For example, a memorable slogan goes a long way keeping the public engaged with your election campaign.

The authors posit that there are two properties of memorable quotes: lexical distinctiveness and generality. Memorable quotes use uncommon words in a common way, meaning they use words which are less frequently used but in a common sentence structure. Memorable quotes are also very general, which makes them applicable in a wide range of situations.

Their data set was full scripts of around 1000 movies. To judge whether a quote from the script is memorable or not, they used the ‘Memorable Quote’ section of IMDB, which is sourced from users i.e. crowdsourced. In addition, they used Google search to search for “quote” + “movie title” and see the result count. Higher the count, higher the memorability.

One of the challenges of the experiment is to separate out the factors that influences memorability. The authors needed to make sure that when they calculate memorability, phrasing of the quotes is the only independent variable. They achieved this by pairing each memorable quote with a non-memorable quote of same word length delivered by the same character in a very close proximity. This made sure that the memorable and non-memorable quotes did not have difference between who delivered the quote and in which context it was delivered. They completed a pilot study with human subjects to make sure that the labeling  of memorable and non-memorable quotes were statistically correct.

To study the lexical distinctiveness of the quotes, the authors employed a Language Model (LM) study. They created a “common language model”, language that is commonly used by an average rational human using the Brown corpus. Then they created six LMs with the quotes: 1-gram, 2-gram and 3-gram word models and 1-gram, 2-gram and 3-gram parts-of-speech models. Now that we have two LMs, we can compare them. We can say how similar are our quotes to the common language model. The results show that memorable quotes are more different when compared to the common language model than non-memorable quotes, ergo, memorable quotes are more distinct. They employ words that are less frequently used in the common language models, but they follow the syntactic patterns of the model.

To study how general the memorable quotes are, they adjudicated them on the following criterion:

1. Fewer 3rd person pronouns – Third person pronouns are harder to apply to newer contexts. It’s easier to apply “I eat ice cream” than “He eats ice cream”, because saying “he” means that another person has to exist. But we can say “I” all the time as it is not dependent on another entity.
2. More indefinite articles – They refer to general concepts.
3. Fewer past tense and more present tense verbs – Using past tense usually means you are referring to concrete actions/situations that have already taken place. Those situations might not be portable to general scenarios.

The results show that memorable quotes meet the aforementioned criteria significantly better than non-memorable quotes.

How can we apply this to write better? One of the obvious application is in advertisement, to write ‘catchy’ quotes. Another obvious application is in political campaigns. But I think we should use these criterion whenever we want the words to stick to the readers. For example, let this two criterion guide you when you are writing the first and last sentences of a paragraph, so that readers remember the gist of it.

What other ways can we take advantage of this study? Drop a comment!

Background

There are multiple recommender system i.e. that spits out recommendation for a particular user. One such method is called content filtering approach where you create profiles for items and users and give recommendation based on those profiles i.e. a person who likes action movies will enjoy movies that are tagged as ‘action’ or you can say that a young male teenager (demographic data), on average, might like a fast-paced, action movie. The obvious downside to this is that you need to gather data about the items and the users. An alternative approach, called collaborative filtering, relies on past user actions to predict future behavior.

The two primary areas of collaborative filtering are the neighborhood methods and latent factor models.

Neighborhood methods

Neighborhood methods are centered on computing the relationships between items or, alternatively, between users. The item oriented approach evaluates a user’s preference for an item based on ratings of “neighboring” items by the same user or a group of users related to each other by some factors i.e. friends etc. A product’s neighbors are other products that tend to get similar ratings when rated by the same user or group of users. Figure 1 from the paper gives a visual explication for neighborhood method:

Figure taken from Koren et al.

Latent factor model (LFM)

LFM relies solely on user ratings for items and infers factors that affected the user’s decision behind the rating i.e. did the user rate Saving Private Ryan high because they love war movies in general?

Matrix Factorization

Our input is the rating matrix R (n x m), where each row is a user and each column is a movie. R(I,j) is the rating user I has given to movie j. We decompose R into two matrices P(n X k) and Q(k X m). P(n x k) denotes the users’ preferences for certain latent factors and matrix Q(k x m) denotes the presence/absence of the aforementioned latent factors in the items (movies and shows for Netflix).  In other words, for a given user u, the elements of P(u) measure the extent of interest the user has in  items that are high on the corresponding factors. For a given item i, the elements of Q(i) measure the extent to which the item possesses those factors. We do not know what these factors are, unfortunately. But, once we have generated P and Q, we can take educated guesses on what they are. For example, after generating P and Q, we see the Saving Private Ryan, Pearl Harbor and Apocalypse Now has high correlation with Factor 1. We also see that User A, who has rated Band of Brother very highly, has a high correlation with Factor 1. Our educated guess, at this point, can be that Factor 1 points to the genre “war shows”.

Decomposing R into latent factor matrices

Given, P and Q, we can calculate R(u,i) by the following formula:

Therefore, if we can populate P(u) for all users and Q(i) for all items, then we can predict ratings by users, which, in turn, can be used to give recommendations. So how do we populate P(u) and Q(i)?

Initially, all entries in the matrices P and Q are unknown. We build P and Q through an optimization process.

How many unknowns do we have? All the entries in P and Q, i.e. we have (nk + km) unknown real numbers. In the optimization process, we will initialize P and Q randomly, and start adjusting all their entries, such that whenever there is a non-missing rating r(i,j) in R, the inner product of corresponding k-dimensional vectors P(i) and Q(j) will approximate the rating r(i,j). I’m using P(i) to denote the i-th row of P and Q(j) to denote the j-th column of Q. Since we know this value, we calculate how good the estimation is by taking the difference between the user given rating and the algorithm approximated rating. Then we adjust P(i) and Q(j) accordingly to minimize this difference a.k.a the error. This is the learning step and the process used by Koren et al. is called stochastic gradient descent.

When some rating r(u,v) is missing in R (user u didn’t rate item v), we just don’t know how to constrain the inner product of P(u) and Q(v), so we will just “let them be” without worrying about them.

But, the user u rated other items, the entries of P(u) will surely be adjusted elsewhere; and similarly, because the item v was rated by other users, the entries of Q(v) will be adjusted elsewhere. So, P(u) and Q(v) are NOT left untouched in the optimization process.

Koren et al. also takes into account user biases, for example, the user being a serious or casual movie reviewer and how they vary over time. They project these biases as functions of time, and use them to learn about user biases, so that they can give the best recommendation based on the user’s current bias. For example, a user might have started their reviewing journey as a casual reviewer but became more critical as life forced them to be more cynical (all hypothetical!). So their initial movie ratings are highly but their recent ratings took a sad, downward turn. A rating of 6 might seem low for an average user, but for this new cynical user, its decent. We need to be able to recognize and utilize these biases.

Moreover, how do you take hype into consideration? We sometimes give higher ratings to a movie not because we absolutely love it but because everyone else loves it. Or, it might be because of extravagant marketing. Koren et al. takes this into consideration by adding a confidence variable to their equation.

The ultimate equation looks like this:

Figure taken from Koren et al.

Here, c(u,i) is the confidence, r(u,i) is the rating given by the user, mu is average rating for all movies, b(u) is the user bias, b(i) is the movie bias and p(u)T.q(i) is the algorithm approximated rating.

Hopefully, this post sheds some light on this amazing paper! It’s simply astounding to see the data they have been able to extrapolate just from user ratings.

Interviewee: Umm, it’s the thing you do in your databases to make queries faster….

Ring a bell? That was the depth of my knowledge about indexes. I decided to learn more when one of my colleague shamed me into doing it. I came across Mark Winand’s “Use the index, Luke!”, a free, online book about, you guessed it, indexes! I wanted to summarize the basic concept of indexes and how they are structured in this post. I am hoping that writing this will force my brain to remember this stuff. I have a hard time remembering stuff.

What is an index?

An index is a data structure, a separate table that contains at least two pieces of information: the data on which the index was created i.e. EmployeeName and a pointer (ROWID/RID) to the DB table row that contains all the information about the indexed data. A database index is, after all, very much like the index at the end of a book: it occupies its own space, it is highly redundant, and it refers to the actual information stored in a different place.

How are they structured?

Indexes combines two data structures, a balanced tree whose leaf nodes are nodes in a linked list, to make searches faster. Each node is called a page and is the basic building block of the table. Each node/page contain a specific number of rows. A picture speaks more than a thousand words:

The leaf nodes each has a nextNode and previousNode pointer. The values in a leaf node and the nodes themselves maintains order i.e. ascending. So the values in Node 2 are bigger than values in Node 1. The largest value in a leaf node makes up a row in a branch node. For example, in the above picture, the first leaf node’s largest value is 46, so the branch node’s first value is 46 and it contains a pointer to the leaf node. The largest value in the branch node becomes the row in the branch node one level up.  The procedure repeats until all keys fit into a single node, the root node. The structure is a balanced search tree because the tree depth is equal at every position; the distance between root node and leaf nodes is the same everywhere.

How are they queried?

We start at the root node and iterate over the values in the node top to bottom until we reach a value that is bigger or equal to the value we are searching. Then we follow the pointer to the branch node and repeat the process until we reach the leaf node that contains the value we are looking for. Since the branch nodes do not contain the ROWID/RID, we have to travel to the leaf nodes to retrieve it. Then we use the ROWID/RID to find the table row we are looking for.

Why use an index?

The costs of traversing an index are:

1. Traversing the tree
2. Traversing the leaf node chain
3. Following the ROWID/RID to access the table data.

Since indexes are sorted and use a balanced tree, the depth of the tree is uniform and the run time to reach the leaf nodes is O(h) where h is the height of the tree. Even index tables with millions of records have a height of 3 or 4. Once, we reach the leaf node, we need to iterate over a handful of entries to find the desired entry. Overall, search becomes extremely fast.

Every night, before falling asleep, I make a mental list of things that I will accomplish the next day. And then I do none of them. I am on a very weird sleep schedule as I am working remotely from home, living in Bangladesh and working in Eastern Time, meaning I go to bed at around 3 am everyday. Waking up at around noon means I waste half of the daily daylight hours. Meals take around 2 hours on average and I spent a couple of hours wasting scrolling on my phone or watching Netflix.

But I want to read more books, read more articles about programming, write more in my blog and finish the course I started in Coursera. I know I should be doing all these to better myself, but I don’t. Then I get frustrated and angry at myself for not sticking to my mental schedule.

This blog post is me saying enough is enough. I am going to force myself to spend a specific amount of time everyday doing things for self-improvement by following the Pomodoro Technique.

I am sure I am not the only one who feels this way. How do you make yourself waste less time? How do you force yourself to do things to better yourself? Drop a line in the comments!