Handling events in React elements has some syntactic differences:

– React event handlers are named using camelCase, rather than lowercase.
– With JSX you pass a function as the event handler, rather than a string.

ref – https://programmingwithmosh.com/javascript/stateful-stateless-components-react/

In a component, state is data we import — typically to show the user — that is subject to change.

Here we have a component Pigeon with a state object that has property pigeons. It is simply an array of pigeons that gets displayed in render. We have state, and we can render things from state.

Also called:

Container vs Presentation components
Smart vs Dumb components.

The literal difference is that one has state, and the other doesn’t.

That means the stateful components are keeping track of changing data, while stateless components print out what is given to them via props, or they always render the same thing.

Stateful/Container/Smart component

Stateless/Presentational/Dumb component

Notice the stateless component is written as a function. As cool as state is, you should always aim to make your components as simple and stateless as possible, so different components can be reused like Lego pieces, even if you don’t have immediate plans to reuse a component. The stateful ones should feel lucky to be so!

Structuring components

Aim to have a parent component keep all the information, and pass it down to its children stateless components.

Doesn’t that look and feel so neat? Having a parent component pass data down to its children also assures that if there is any debugging needed regarding state management, we can go to the parent component to see what’s up, instead of checking state in each child component. All the children components have to worry about is receiving the information as props properly.

So presentational components can vary depending on what information it receives. The difference is that a stateful component keeps track of the information itself, instead of just taking it via props and outputting it.

We can also have components that render static state:

Generally, child components render UI and have no state.

Creating reusable component

Create a stateless reusable component like so:

then use it like so:

class is a keyword in JavaScript.

JSX is an extension of JavaScript. That’s the reason why React uses className instead of class.

Pass a string as the className prop.

Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language.

Problem

Using context, we can avoid passing props through intermediate elements:

Solution

What is children prop?

Children is a prop this.prop.children that allow you to pass components as data to other components, just like any other prop you use. Component tree put between component’s opening and closing tag will be passed to that component as children prop.

There are a number of methods available in the React API to work with this prop. These include React.Children.map, React.Children.forEach, React.Children.count, React.Children.only, React.Children.toArray.

A simple usage of children prop looks like this:

If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context

Component composition

Components use the special children prop to pass children elements directly into their output:

This lets other components pass arbitrary children to them by nesting the JSX:

You can also specify where you want children props to go. In our case, we can position prop children to be placed in certain areas.

We can even specialize it:

Inversion of Control

It might feel redundant to pass down the user and avatarSize props through many levels if in the end only the Avatar component really needs it. It’s also annoying that whenever the Avatar component needs more props from the top, you have to add them at all the intermediate levels too.

One way to solve this issue without context is to pass down the Avatar component itself so that the intermediate components don’t need to know about the user or avatarSize props:

This inversion of control can make your code cleaner in many cases by reducing the amount of props you need to pass through your application and giving more control to the root components. However, this isn’t the right choice in every case: moving more complexity higher in the tree makes those higher-level components more complicated and forces the lower-level components to be more flexible than you may want.

You’re not limited to a single child for a component. You may pass multiple children, or even have multiple separate “slots” for children, as documented here:

ref – http://chineseruleof8.com/code/index.php/2020/06/29/why-we-must-bind-prototype-functions-for-event-handlers-in-react/

source code

create-react-app index-list-example
cd index-list-example
npm start

Go your App.js and change the functional component into a class component.
1) add ‘class App extends React.Component’
2) add constructor
3) add a render prototype function

We then add a state property called list. It’s an array to simply display our list of data.
We put code to map through this list in function render:

Displaying Item data

Now, let’s write a function called Item that will display each item in the list.
As a function component, it takes the prop as a parameter. We use this prop to get each item from the list.
Then display the properties name/id from each item and display it.

then use this Item component in render:

Add items to the list

First, let’s create a button. Remember that standalone functions (due to being referenced in global environment and being run in strict mode), will dynamically
(http://chineseruleof8.com/code/index.php/2020/06/29/why-we-must-bind-prototype-functions-for-event-handlers-in-react/)
set ‘this’ to undefined, we must bind it correctly.

Then in render, we put a button and handler there:

Run it

First, write your name at the top. Then click the button to add items.

When you first write the name ‘ted’, and assigns the index to the key of that component, React will think that ‘ted’ should always appear at index 0.

Thus, as you keep adding items, ted stays at index 0.

However, say we add item to front of the list

Make this code change in prototype function addItem:

Now run it again. We put Mike at the box with timestamp of …940:

However, when we append more items to the front of the list, the name Mike gets displayed erroneously index 0, instead of the correct textfield at …940.

This happens because we erroneously assigned array index to our key. As each Items appear, React will assign different index each time these items are rendered. For example, the first time item1 appears, it gets 0. We append item2 on top, so item2 gets 0, item1 gets 1. See? Their keys have changed. ‘mike’ always gets assigned to key 0, and thus, when item2 appears, it appears in item2, instead of item1.

Solution

The solution to this is to use a unique id as key. Notice when we assigned timestamp to our object’s name, we also assign it to id. Timestamp is unique so every entry will be different. This means every entry’s key will be unique. Thus when they get rendered, their respective data will always be matched to the Component Item’s key. Thus, if we were to put ‘ricky’ at an Item1, no matter what kind of Items get appended at anywhere, React will also look for the Component that has the key with the unique ID to insert ‘ricky’ in.

Full Source

The idea is that Then JSX gets transpiled to Plain Javascript Objects using React.createElement().
Then it compiles those objects down to DOM elements.

There are four different phases of React component’s lifecycle:

Initialization: In this phase react component prepares setting up the initial state and default props.

Mounting: The react component is ready to mount in the browser DOM. This phase covers componentWillMount and componentDidMount lifecycle methods.

Updating: In this phase, the component get updated in two ways, sending the new props and updating the state. This phase covers shouldComponentUpdate, componentWillUpdate and componentDidUpdate lifecycle methods.

Unmounting: In this last phase, the component is not needed and get unmounted from the browser DOM. This phase include componentWillUnmount lifecycle method.

ref – https://reactjs.org/docs/higher-order-components.html
https://www.codingame.com/playgrounds/8595/reactjs-higher-order-components-tutorial

Whereas a component transforms props into UI, a higher-order component transforms a component into another component.

A HOC doesn’t modify the input component, nor does it use inheritance to copy its behavior. Rather, a HOC composes the original component by wrapping it in a container component. A HOC is a pure function (does not modify outside values, unique input/output) with zero side-effects.

And that’s it! The wrapped component receives all the props of the container, along with a new prop, data, which it uses to render its output. The HOC isn’t concerned with how or why the data is used, and the wrapped component isn’t concerned with where the data came from.

Let’s look at an example. Create a simple React app like so.

npm install -g create-react-app
create-react-app my-app

cd my-app
npm start

It’s only a Higher Order component by definition because it does not modify outside values. It simply take another component as input and renders it.

Let’s create a generic utility component that displays data in a row. It will be used by two other components.

TableRow.js

StockList.js

Now we use that StockList in our App.

Everything is standard. We display a component inside of another component. But let’s say we want to add UserList, which is very very similar to StockList.

It even uses the TableRow component in the same way. Can we somehow refactor these two components into one?

This is where HOC comes into play. We can implement reusability of particular components in multiple modules or components.

Take a look at how we’d factor this. Let’s create an HOC file.

HOC.js

In our HOC, we receive the two components. However, we combine the functionality of passing data to them. Instead of them having its own data state.
Hence, we receive data from the parameter and use prop to pass it into those Wrapped components.

In our redundant components, our this.prop will have the data we need, instead of us keeping the data state in our component.
Thus, we use it right away in our render functions.

StockList.js

In both UserList and StockList, we are doing the same thing.
Just display the stocks and users properties id and name.
So here our component gets passed into our HOC, which then fills our
this.prop with the new data.

We then can display it.

UserList.js

We pull the data state out. Then pass both data and components into HOC, which creates two different components.

App.js

Because Hoc is a normal function, you can add as many or as few arguments as you like. For example, you could accept an argument that configures shouldComponentUpdate, or one that configures the data source. These are all possible because the HOC has full control over how the component is defined.

Like components, the contract between Hoc and the wrapped component is entirely props-based. This makes it easy to swap one HOC for a different one, as long as they provide the same props to the wrapped component. This may be useful if you change data-fetching libraries, for example.

Don’t Mutate the Original Component. Use Composition.

Resist the temptation to modify a component’s prototype (or otherwise mutate it) inside a HOC.

– The input component cannot be reused separately from the enhanced component because it depends on the original functionality of the input component. If you change it in your HOC, then your enhanced component will function differently from the original component.

– If you apply another HOC to EnhancedComponent that also mutates componentDidUpdate, the first HOC’s functionality will be overridden!

– Mutating HOCs are a leaky abstraction—the consumer must know how they are implemented in order to avoid conflicts with other HOCs.

Instead of mutation, HOCs should use composition, by wrapping the input component in a container component. In our example, we create a class component, then implement our componentDidUpdate the way we want, and then wrap our component inside the render via composition.

This HOC has the same functionality as the mutating version while avoiding the potential for clashes.
– It works equally well with class and function components.
– Because it’s a pure function, it’s composable with other HOCs, or even with itself.

Container components are part of a strategy of separating responsibility between high-level and low-level concerns. Containers manage things like subscriptions and state, and pass props to components that handle things like rendering UI. HOCs use containers as part of their implementation. You can think of HOCs as parameterized container component definitions.

Don’t Use HOCs Inside the render Method

React’s diffing algorithm (called reconciliation) uses component identity to determine whether it should update the existing subtree or throw it away and mount a new one.

When its analyze the previous and current render, it looks at the previous and current component. If the two components are identical (===), React will leave the subtree be, and continue to update the subtree by diffing it with the new one. If they’re not equal, the previous subtree is unmounted completely.
This means you can’t apply a HOC to a component within the render method of a component because for every render, a new component (object) returned. Hence every compare will be different and thus, the entire subtree will be remount each time.

Remounting a component causes the state of that component and all of its children to be lost also.

Instead, apply HOCs outside the component definition so that the resulting component is created only once. Then, its identity will be consistent across renders. This is usually what how you use it.

In those very rare cases where you need to apply a HOC dynamically, you can also do it inside a component’s lifecycle methods or its constructor.