Forem: pulkitnagpal

Transpile JSX using your own custom built babel plugin

pulkitnagpal — Sun, 16 Aug 2020 15:47:20 +0000

Ever wondered how does react jsx code (<div>Hello World</div>) gets compiled to React.createElement("div", null, "Hello World"). This blog is all about this compilation process by taking help from the source code of babel-preset-react and trying to build our own custom plugin.

Just to make things clear, I will not use Webpack at all because its significance lies in just bundling process. It has nothing to do with transpilation part. I will just use babel and 3 files. Thats it. No HTML nothing. The goal of this blog is to actually convert this jsx code to js code that browsers can really understand.

Github Link -> https://github.com/pulkitnagpal/custom-jsx-plugin

Before moving straight to the code, lets revise some basics

Basics

I tried this <div>Hello world</div> code in a normal script tag and got "Unexpected token <". I thought create-react-app does everything under the hood and does some magic to convert it into React.createElement syntax.
Everyone must know that this div in jsx is not an actual HTML Element. The compilation process just converts it into a function call. Not into HTML Element. That part is done by react.

I dug further and gradually realised that there is some power(apologies for using it :P) that converts this jsx into a function call like syntax. This power is harnessed by BABEL.

create-react-app and many other tools uses babel under the hood.

How does Babel works ?

Parses your code => Babel converts your code to AST(Abstract Syntax Tree). Heavy term right ? No problem try this tool (https://astexplorer.net/). Try writing something on the left and a tree like structure will be generated on the right. This is done by a parser built inside babel.
Traverse & Transform => This is where babel plugins and presets comes into play. A visitor pattern is provided by babel that let us traverse through all the tree nodes of AST and transform/manipulate those nodes into something we desire.
Generate => This is the stage where babel converts the transformed tree back into human readable code.

Before moving to our own custom plugin, let's try to use already built react preset and transpile our index file using babel cli.

Steps to install babel-cli are mentioned here
Install React and ReactDOM and react preset
Create an index.js file and .babelrc file

Add this to index file

ReactDOM.render(<div><p>Hello World</p></div>, document.getElementById("root"))

and this to .babelrc

{
  "presets": ["react"]
}

Run this command on the terminal
node ./node_modules/babel-cli/bin/babel index.js

and we can see the transpiled code on the terminal screen. We can also create separate output file. But I wanted to make things simple. As we can see how this jsx code got transpiled to React createElement syntax. We will try to build our own plugin that will do the same thing.

NOTE: I will ignore the props and attributes part of the jsx in the custom plugin.

Custom-jsx-plugin

Clear the .babelrc file.

Create a new file custom-jsx-plugin.js

Try below code in (https://astexplorer.net/) to get an overview on how jsx code looks like in AST

function anything() {
  return <div><p>Hello World</p></div>
}

and as we can see on the right side. The jsx part has a node type of JSXElement. This is what we need to manipulate and replace it with a CallExpression as React.createElement is actually a javascript function.

When you try to parse this jsx using your local babel cli, you will get a syntax error. Because the parser does not know anything about the jsx syntax.
Thats why we need to add a file which manipulates the parser, name it as jsx-syntax-parser.js

jsx-syntax-parser.js

module.exports = function () {
  return {
    manipulateOptions: function manipulateOptions(opts, parserOpts) {
      parserOpts.plugins.push("jsx");
    }
  };
};

and now our new .babelrc file will look like

{
  "plugins": ["./custom-jsx-plugin", "./jsx-syntax-parser"]
}

The order of plugins matter and its actually in the reverse order. Right to Left. First our syntax parser will be executed which tells babel that it needs to parse jsx syntax also and then it will execute our custom plugin file which is for now empty.

As we still have not written anything inside our custom-jsx-plugin file. The output of babel transpilation will be same as the index file. Nothing should have been changed.

Add this to custom-jsx-plugin file

module.exports = function (babel) {
  var t = babel.types;
  return {
    name: "custom-jsx-plugin",
    visitor: {
      JSXElement(path) {
        //get the opening element from jsxElement node
        var openingElement = path.node.openingElement;  
         //tagname is name of tag like div, p etc
        var tagName = openingElement.name.name;
        // arguments for React.createElement function
        var args = []; 
        //adds "div" or any tag as a string as one of the argument
        args.push(t.stringLiteral(tagName)); 
        // as we are considering props as null for now
        var attribs = t.nullLiteral(); 
        //push props or other attributes which is null for now
        args.push(attribs); 
        // order in AST Top to bottom -> (CallExpression => MemberExpression => Identifiers)
        // below are the steps to create a callExpression
        var reactIdentifier = t.identifier("React"); //object
        var createElementIdentifier = t.identifier("createElement"); //property of object
        var callee = t.memberExpression(reactIdentifier, createElementIdentifier)
        var callExpression = t.callExpression(callee, args);
         //now add children as a third argument
        callExpression.arguments = callExpression.arguments.concat(path.node.children);
        // replace jsxElement node with the call expression node made above
        path.replaceWith(callExpression, path.node); 
      },
    },
  };
};

And thats it. These 12 lines of code can easily transpile our jsx code.
Run this command again on the terminal
node ./node_modules/babel-cli/bin/babel index.js

and notice that the result is the same as created by react-preset

like this
ReactDOM.render(React.createElement("div", null, React.createElement("p", null, Hello World)), document.getElementById("root"));

Explanation of the code

In the visitor pattern of babel, during traversal of the AST, for every JSXElement node, this callback function as defined above will be executed.
This node has two parts opening and closing elements. The name of opening element (eg "div") is extracted to be used as first argument of the function (React.createElement)
The second argument (props or attributes) is considered as null for this example. Ignoring props just for simplicity.
Now to create a function call, we will need to create 3 things CallExpression => MemberExpression => Identifiers. The 2 identifiers used here are obviously React as an object and createElement as the property.
Then we need to concat the rest arguments which are the child nodes of current node.
At last we need to replace(used inbuilt function of path) the current JSXElement node with the callExpression node you have created. This modifies the AST.

Conclusion

This is obviously not a production ready code. I have taken help from the source code of babel-preset-react and just to make things simpler I made the code shorter for better understanding. It is just the basic overview of how does this plugin works under the hood.

Need of Concurrent mode(Experimental) in React

pulkitnagpal — Sun, 21 Jun 2020 17:09:44 +0000

Today I will discuss some of my observations on concurrent rendering in react which is still in experimental stage.

React and its libraries are fully written in javascript and this whole bunch of javascript runs on the main thread. The main thread also runs DOM updates, browser paints etc. Mainly javascript runs on a single main thread, which makes the react render and updates blocking.

Use Case 1:

Think of a video streaming app. When some streaming api call is done and wants to execute the callback associated with it, but could not execute at that time as some other react related (rendering of some complex nested component) is going on.
It has to wait for the react to finish rendering and then execute.

Use Case 2:

Think of a user input component, when user types a key, a re render of a complex nested list needs to be done. The user will be stuck between 2 key presses, which leads to jarring experience and bad UI.
This happens because the browser needs some empty space or slot in the main thread at that moment of time to print the input and show it to the user, but it is blocked by that react heavy re render.

Concurrent rendering came into play to solve the above issues.
Basically react decides which task is high priority and which is low and accordingly update its components. User input component re render is taken as high priority than complex nested list ongoing render and pauses this render for a while which lets the user see what he/she is typing, and then continue with where it left with the heavy re render.
This is the concurrent way of working.

Let's understand through a code example

There are 2 cases taken into consideration, one is "blocking rendering" (currently how react works) and other is "interruptible rendering" (concurrent react).

Consider a huge list of nested components (around 100) and also 50 such sibling components.
Every Element component gets a count value from its parent. The root component App decides what would be the value of the count. After every 10ms, we tend to set the new count. Have used setInterval for this and it will be started after button click. This interval will be cleared after 5 seconds of button click.

After clearing we will see how many times 'actually fired' is consoled on the browser.
The purpose behind this is to find how many times setInterval callbacks are fired within a specific timeframe.

Also find codesandbox link below the explanation

Synchronous Rendering

Use the common render function in index.js file

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

App js file

class App extends React.Component {
  constructor() {
    super();
    this.interval = null;
    this.state = {
      value: 0,
    };
  }
  handleClick = () => {
    let startTime = Date.now();
    this.interval = setInterval(() => {
      if (Date.now() - startTime > 5000) {
        this.handleStop();
        return;
      }
      console.log('actually fired');
      let i = 10000;
      // complex operation or some api call which sets the state after its completion
      while (i > 0) {
        i--;
      }
      if (i === 0){
        this.setState((state) => {
          return { value: (state.value + 1) };
        });
      }
    }, 10);
  };
  componentWillUnmount() {
      clearInterval(this.interval)
  }
  render() {
    return (
      <div style={{ fontSize: 16, lineHeight: 1 }}>
        <button onClick={this.handleClick}>Start interval</button>
        <div style={{ display: "flex" }}>
          {
            heavyList.map(() => {
              return (
                <div>
                  <Element value={this.state.value} nestingCount={100}/>
                </div>
              )
            })
          }
        </div>
      </div>
    );
  }
}

Element component nested 100 times using recursion

class Element extends React.Component {
  render() {
    if (this.props.nestingCount === 1) return null;
    return (
      <div style={{ marginLeft: "0.4px" }}>
        {this.props.value}
        <Element
          value={this.props.value}
          nestingCount={this.props.nestingCount - 1}
        />
      </div>
    );
  }
}

Now there are 5000 elements on the screen as you can see.
Click the Start interval button and wait for 5 sec and notice that the setInterval callback was called ~37 times and this can be confirmed by number of times 'actually fired' is consoled in the browser.
It may show different count on different browsers. But the point is to show this count in relation to the next(concurrent) type of rendering.
Latest Element count will be ~37 on the screen.
This is because as explained above heavy rendering is blocking the main thread and react can not acknowledge the setInterval callback unless its render part is done.

Lets look at profiling of synchronous behaviour

As you can see in the above chrome profile. The red boxes marks the calling of the setInterval callback and the corresponding setState. This callback is finished executing only after whole render tree is updated, paints it on the browser and then is able to give space to the upcoming callback.

Concurrent Rendering

Just change this in the index js file

ReactDOM.unstable_createRoot(
  document.getElementById('root')
).render(<App />);

and do the same thing, click the button, wait for 5 seconds and see the magic.
This time actually fired is consoled ~150 times, and the latest Element count is also ~150. This means the setInterval is acknowledged more number of times this time.
This is possible because react pauses the heavy rendering and prioritise the new state as more, and works on it and comes back to where it left.

Lets look at the profiling of concurrent rendering

As you can notice the red boxes in the above profile, which represents setInterval callbacks are executed in between the renders (concurrent behaviour). The render process is actually interrupted unlike in above example.

I tried the same examples with an object animating using requestAnimationFrame() along with this counter. Got smoother animation in concurrent mode when compared to that using normal case.

Switch between concurrent and the usual reactDom render in the index file.
Click on the box to start animation and click the Start interval when the animation is happening. You can click on the box as many times in 5sec to see the effects.
Open in separate window if animation is not working here.

Using Throttling and Debouncing with React hooks

pulkitnagpal — Sat, 13 Jun 2020 23:29:15 +0000

Throttling and debouncing techniques has been in use for past many years in javascript.
In this post I'd like to share my knowledge on how we can use throttle and debounce functions with help of react hooks.

Consider below example with two routes / and /count rendering respective components.

export default function App() {
  return (
    <BrowserRouter>
      <div>
        <nav>
          <ul>
            <li>
              <Link to="/">Home</Link>
            </li>
            <li>
              <Link to="/count">Count</Link>
            </li>
          </ul>
        </nav>
        <Switch>
          <Route path="/count">
            <Count />
          </Route>
          <Route path="/">
            <Home />
          </Route>
        </Switch>
      </div>
    </BrowserRouter>
  );
}

Throttling Example with useEffect

Suppose we need to subscribe a scroll event on Count component on its mount and just increment the count on every scroll event.

Code without using throttle or debounce techniques will be like:

function Count() {
  const [count, setCount] = useState(1);
  useEffect(() => {
    window.addEventListener('scroll', increaseCount);
    return () => window.removeEventListener('scroll', increaseCount);
  }, []);
  const increaseCount = () => {
    setCount(count => count + 1);
  }
  return <h2 style={{marginBottom: 1200}}>Count {count}</h2>;
}

Suppose in practical applications you need to use throttle and wait for every 100ms before we execute increaseCount. I have used the lodash throttle function for this example.

function Count() {
  const [count, setCount] = useState(1);
  useEffect(() => {
    window.addEventListener('scroll', _.throttle(increaseCount, 100));
    return () => window.removeEventListener('scroll', _.throttle(increaseCount, 100));
  }, []);
  const increaseCount = () => {
    setCount(count => count + 1);
  }
  return <h2 style={{marginBottom: 1200}}>Count {count}</h2>;
}

Wait, no need to hurry. It will work if you are at /count route. The increaseCount function will be throttled and will increase the count after 100ms of intervals.

But as you move to the / route to render the Home component and unmount the Count component, and start scrolling on home page, you will notice a warning in console which warns about memory leak. This is probably because the scroll event was not cleaned properly.
The reason is _.throttle(increaseCount, 100) is called again during unmount and returns another function which does not match that created during the mount stage.
What if we create a variable and store the throttled instance.

like this

const throttledCount = _.throttle(increaseCount, 100);
useEffect(() => {
    window.addEventListener('scroll', throttledCount);
    return () => window.removeEventListener('scroll', throttledCount);
  }, []);

But it has problem too. The throttledCount is created on every render, which is not at all required. This function should be initiated once which is possible inside the useEffect hook. As it will now be computed only once during mount.

useEffect(() => {
    const throttledCount = _.throttle(increaseCount, 100);
    window.addEventListener('scroll', throttledCount);
    return () => window.removeEventListener('scroll', throttledCount);
  }, []);

Debounce Example using useCallback or useRef

Above example is pretty simple. Let's look at another example where there is an input field and you need to increment the count only after user stops typing for certain time. And there is text which is updated on every keystroke which re renders the component on every input.

Code with debounce:

function Count() {
  const [count, setCount] = useState(1);
  const [text, setText] = useState("");
  const increaseCount = () => {
    setCount(count => count + 1);
  }
  const debouncedCount = _.debounce(increaseCount, 1000);
  const handleChange = (e) => {
    setText(e.target.value);
    debouncedCount();
  }
  return <>
    <h2>Count {count}</h2>
    <h3>Text {text}</h3>
    <input type="text" onChange={handleChange}></input>
  </>;
}

This will not work. The count will increase for every keystroke. The reason behind is that on every render, a new debouncedCount is created.
We have to store this debounced function such that it is initiated only once like that in useEffect in above example.
Here comes use of useCallback.
useCallback will return a memoized version of the callback that only changes if one of the dependencies has changed - React docs
Replace

const debouncedCount = _.debounce(increaseCount, 1000);

with

const debouncedCount = useCallback(_.debounce(increaseCount, 1000),[]);

and it will work. Because this time the function is evaluated only once at the initial phase.

Or we can also use useRef
by doing this

const debouncedCount = useRef(debounce(increaseCount, 1000)).current;

One should always keep in mind that every render call of react functional component will lead to expiration of local variables and re-initiation unless you memoize them using hooks.