DEV Community: Benjamin Liu

Memoisation in React

Benjamin Liu — Sat, 13 Mar 2021 03:22:49 +0000

Memoisation is an optimisation technique that caches the result of previous computations so that they can be quickly accessed without repeating the same computation.

React introduces quite a few memoisation functions being React.memo, useMemo and useCallback.

1. React.memo

React.memo is a higher order component when wrapped around a component, memoises the result of the component and does a shallow comparison before the next render. If the new props are the same the component doesn't re-render and uses the memoised result.

By default memo does a shallow comparison of props, however, the second argument allows you to define a custom equality check function. From React's official docs:

function MyComponent(props) {
  /* render using props */
}
function areEqual(prevProps, nextProps) {
  /*
  return true if passing nextProps to render would return
  the same result as passing prevProps to render,
  otherwise return false
  */
}
export default React.memo(MyComponent, areEqual);

However, if you're looking to do a deep comparison between 2 values and want to take the easy route you can use isEqual from lodash.

Now let's have a look at this example:

// App.js
import React, { useState } from "react";

import Child from "./Child.js";

const App = () => {
  const [counter, setCounter] = useState(0);
  const [text, setText] = useState("");

  return (
    <div className="App">
      <input
        onChange={(e) => setText(e.target.value)}
        type="text"
        value={text}
      />
      <button onClick={() => setCounter(counter + 1)}>+ 1</button>
      <Child counter={counter} />
    </div>
  );
};

export default App;

In this case we have a parent component called App which takes in a <Child /> component.

import React from "react";

const Child = ({ counter }) => {
  console.log("rendering...");

  return <div>Count: {counter}</div>;
};

export default Child;

If you open up Console you will notice that given each keystroke in the input field the <Child /> component re-renders. Obviously this doesn't have any performance overhead at this point in time, but imagine if the Child component had child components of its own with state. Then you'd trigger a re-render of all components associated with the parent, that'd definitely add overhead to your application.

To prevent child components from unnecessarily re-rendering like that we have to use React.memo. All we need to do is wrap our Child component in our memo and you see that no matter what we type in the input field it doesn't trigger a re-render of the <Child /> component.

import React, { memo } from "react";

const Child = ({ counter }) => {
  console.log("rendering...");

  return <div>Count: {counter}</div>;
};

export default memo(Child);

However, what if we wanted to pass down functions or anything that isn't a primitive value such as objects since memo only does a shallow comparison? A shallow comparison in this case means it only checks if the props that you're passing down is referencing the same place in memory.

So let's say we want to update the counter from <Child /> so we do something like this:

// App.js
import React, { useState } from "react";

import Child from "./Child.js";

const App = () => {
  const [counter, setCounter] = useState(0);
  const [text, setText] = useState("");

  const updateCounterHandler = () => {
    setCounter(counter + 1);
  };

  return (
    <div className="App">
      <input
        onChange={(e) => setText(e.target.value)}
        type="text"
        value={text}
      />
      <button onClick={() => setCounter(counter + 1)}>+ 1</button>
      <Child counter={counter} updateCounter={updateCounterHandler} />
    </div>
  );
};

export default App;

and within Child.js:

import React, { memo } from "react";

const Child = ({ counter, updateCounter: pushUpdateCounter }) => {
  console.log("rendering...");

  return (
    <div>
      <strong>Count: {counter}</strong>
      <button onClick={pushUpdateCounter}>Update Counter</button>
    </div>
  );
};

export default memo(Child);

However, you will notice that the <Child /> component still gets rendered whenever we type something into the input field. This is because the updateCounterHandler inside App.js gets recreated each time the state changes.

So the correct way to handle callback functions with memo is by using useCallback.

2. useCallback

useCallback is a hook that comes with react that returns a memoised function. It takes in 2 arguments, the first one being the callback function, the second being an array of dependencies.

So all that needs to be done is wrap useCallback around our updateCounterHandler function to prevent the <Child /> component from re-rendering whenever we type in the input field.

const updateCounterHandler = useCallback(() => {
    setCounter(counter + 1);
  }, [counter]);

3. useMemo

Like useCallback, useMemo is a hook that takes in a function, however, instead of returning a memoised function it returns a memoised value. This makes it useful when performing heavy calculations.

import React, { memo, useMemo } from "react";

const Child = ({ counter, updateCounter: pushUpdateCounter }) => {
  console.log("rendering...");

  const outputNumber = useMemo(() => {
    let output = 0;

    for (let i = 0; i < 10000000; i++) {
      output++;
    }

    return output;
  }, []);

  return (
    <div>
      <strong>Count: {counter}</strong>
      <div>Output Number: {outputNumber}</div>
      <button onClick={pushUpdateCounter}>Update Counter</button>
    </div>
  );
};

export default memo(Child);

Using useMemo in the example above, we're able to cache the return value of outputNumber, so that we're not recalling the function each time.

After learning these techniques, I hope you're able to apply it to where it's truly needed, because premature optimisation is the root of all evil! It's about finding the fine line between compromising space and time as speed optimisation techniques such as memoisation eat up space (RAM) in return for a faster time. So always question yourself before optimising your code, "do the performance gains really justify the usage?".

Tools to optimise the performance of your React app

Benjamin Liu — Mon, 08 Mar 2021 10:55:40 +0000

Although React provides many optimisations for your code out of the box, it is important to nonetheless properly evaluate and optimise the performance of your React app.

I've found these tools to be most helpful during the development process to help optimise an application.

1. Lighthouse

Right click on a page and click Inspect to open developer tools, click on the >> and you will find Lighthouse if it doesn't already show in the tab.

Lighthouse will generate a report of that website by assessing in Performance, Accessibility, Best Practices and SEO.

2. Profiler

Prior to using Profiler you must have installed React Developer Tools from the Chrome web store as it is a dev tools extension.

Once you have that installed you should be able to see Profiler in your developer tools. Close and reopen your browser if you don't see it.

To get started, hit the record icon and make some changes on the page and hit the record icon again to stop.

The Profiler will give you a break down of all Components rendered on the page and how long each one is taking to render.

3. Webpack Bundle Analyzer

Webpack Bundle Analyzer is a tool that generates an interactive treemap visualisation of the contents of your bundle.

You will be able to identify dependencies that take up a significant amount of storage. In the example above, the entire lodash library was imported for a project. To reduce the bundle size we can introduce tree shaking on the lodash package. Essentially, only installing the functions that we need.

Before:

import _ from "lodash";

const object = { 'a': 1, 'b': '2', 'c': 3 };
const omittedObj = _.omit(object, ['a', 'c']);

return omittedObj;

After:

import omit from "lodash/omit";

const object = { 'a': 1, 'b': '2', 'c': 3 };
const omittedObj = omit(object, ['a', 'c']);

return omittedObj;

Thank you for reading! I hope that you will incorporate these technologies and practices into your projects as it will definitely help you write sustainable and reliable code!

Show, Don't Tell: A Story of Management.

Benjamin Liu — Tue, 03 Dec 2019 04:11:54 +0000

If you are a senior developer, it is your responsibility to ensure that your team members stay on track to complete their assigned tasks, whilst also being in a positive and encouraging state of mind.

Actions speak louder than words. We've all heard this quote before, but how many of us actually take this seriously?

We've all met someone who makes promises without any intention of keeping it, in fact you've mostly likely unintentionally done the same.

The problem

Jerry is a member of your development team. A junior developer with a lot of promise, during meetings he always contributes amazing ideas and brings forth great energy; however, when asked to do solid work, he always slacks off, coming to work as late as possible, and leaving on the dot. You're aware that Jerry has the potential to do amazing things, but his actions aren't mirroring his words.

Why is that?

There definitely can be something happening in his personal life that is causing this disconnect. However, let's assume for the sake of this article that Jerry consistently shows this type of behaviour for weeks and months on end.

Why is that?

The cause

I'm here to share the (possibly controversial) opinion that Jerry isn't lazy. In fact, no one is lazy. The only reason he appears lazy (i.e. there is a disconnect between his words and his actions) is because he feels comfortable within a company culture that encourages and rewards ideas without action.

The company culture can involve explicitly stated elements (e.g. "we wear formal attire to work every day"), but in many cases it is implicitly stated (e.g. as the technical lead, by coming in first and leaving last, you're fostering a culture of over-achievement).

The solution

You realise that ideas are commonly being put forth in standup meetings, by Jerry and also by others, but they’re not being objectively evaluated, recorded and assigned accordingly, and that as a result, Jerry isn't realising the importance of delivering features on time.

You realise that although Jerry is displaying the most obvious symptoms of this issue, your whole team seems to be living in some degree of disconnection between their words and their actions.

You take action and decide to make it a note to include the development team in your next planning meeting with the technical lead, so that they can see the business implications of their actions/non-actions. By doing so, the entire team is able to see what needs to be done.

Specifically for Jerry, you organise some one-on-one planning time each sprint, not only to go through scheduling for his work, but also as a good opportunity to catch up and build rapport. Jerry responds well to this indirect counselling, and his performance quickly improves, making him not only a wonderful fountain of ideas, but also a hard worker who is an invaluable asset to the company.

"If everyone is moving forward together, then success takes care of itself."

– Henry Ford

Thanks for reading! What do you guys think? Do you have any similar stories?

The Twelve-Factor App: How To Embrace The Future

Benjamin Liu — Sat, 30 Nov 2019 09:17:35 +0000

In this article, I will explain to you the Twelve-Factor App development guidelines, why it's not a passing fad, and how you can use it to literally (well, figuratively) embrace the future.

What Is The Twelve-Factor App?

The Twelve-Factor app is a set of best practices for building modern web applications. There are twelve guidelines (hence the name) that are recommended to be followed by every developer to build scalable applications.

A Twelve-Factor App is described as:

Automated from a development perspective;
Portable across execution environments;
Deployable in the cloud minimizing the need for servers and server administration;
Enabled for continuous deployment with minimal divergence between development and production environments; and
Scalable without significant change or effort.

What Are The Twelve Factors?

I'll briefly cover each of the factors. However, for an in-depth explanation be sure to check out the official site of The Twelve-Factor App: https://12factor.net/

1. Codebase

Essentially, there will always be only one code repository for a given app. This can be any version control system such as Git, Mercurial or Subversion. There will be many deployments of an app, however, the app can be run in different environments (local/production).

2. Dependencies

NEVER directly copy a dependency into your codebase. You want to use a package manager to explicitly declare and isolate your dependencies. For JavaScript, popular package managers include npm or yarn.

3. Config

The config should always be stored in an Environment Variable. You want the config file to be separated away from the code as the config varies throughout deployment and the code does not.

4. Backing services

Treat your backing services as attached resources. This means that you want to make your services easily interchangeable so that you can swap to a different third-party service provider without any changes to the app’s code.

5. Build, release, run

The twelve-factor app uses strict separation between the build, release, and run stages. The build process is run when new code is deployed. Every release should always have a unique release ID, such as a timestamp of the release or an incrementing number. Then you are able to run the release in an execution environment.

6. Processes

DO NOT introduce state in the processes. Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.

7. Port binding

The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. Make sure that you export your services via port binding. The service should be visible to other services as they may be used.

8. Concurrency

By separating your app into smaller pieces you are able to scale the services. This reduces the workload as an individual VM can only grow so large (vertical scale), so it is important for the app to span across multiple processes on multiple physical machines.

9. Disposability

Processes are disposable, so make sure that they can be started or stopped fast. By doing so this facilitates automatic scaling, rapid and ease of deployment.

10. Dev/prod parity

Keep development, staging, and production as similar as possible so that anyone working on a project is able to pick it up and release it. Continuous deployment between development and production is imperative to limit failures and errors.

11. Logs

Treat logs as event streams. Logs are useful for checking up on your apps processes and backing services. You should never concern the routing or storage of its output stream with your app. Instead, think of these logs as having no fixed beginning or end but flows on a continuous stream as long as the app is running.

12. Admin processes

Run admin/management tasks as one-off processes for tasks like database migrations and executing one-time scripts in the environment.

What Now?

Regardless of your framework and tech stack, you can implement Twelve-Factor App principles into your application! Some great resources that naturally complement the Twelve-Factor App's principles include:

Dotenv for configuring environments (the link is for Node.js but different versions are available for different languages and frameworks)
Docker for setting up containers and creating perfect development/deployment environments effortlessly;
Kubernetes for managing and scaling containers for production-grade uses;
AWS for hosting a deployed Twelve-Factor App; and
So many more!

This above list is by no means exhaustive. I'll end this article encouraging you to do your own research and find more tools that you can incorporate into your stack. Like it or not, these Twelve-Factor App principles are becoming more and more common, so the best time to get started is now!

When should you ask for help? Tips from a senior developer.

Benjamin Liu — Tue, 26 Nov 2019 01:35:49 +0000

As a senior JavaScript developer, I've worked with and mentored many developers; and over all these years, there are two types of people that bother me the most.

The ones that ask too many questions. e.g. How do you loop through an array? How do you use a reducer? Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for a lifetime. I'd much rather junior developers spend 30 minutes researching a problem and finding a solution, and learning self-sufficiency skills along the way, than I help them fix it in 3 minutes time, and they don't have half a clue what's going on.
The ones that ask too few questions. Afraid of being scrutinised and/or looking to protect their self-esteem, some developers will persist even when they sense something isn't right. Thousands of lines of code later, you end up spending an exponential amount of time understanding and refactoring their mess. What started with a single instance of inheritance on class-based React components then turns into a full-scale "inheritance suite" using poorly-designed OOP models to poorly deliver a solution in "React".

To be fair, it is definitely quite daunting to ask for help. You feel like you're being judged for not knowing something, and you're afraid of asking a stupid question.

So, when should I ask for help?

whathaveyoutried.com

(^ have a read)

Here's a procedure I share with others to help them determine when to ask for help:

Can you find/derive a high-quality solution from the internet? If your problem is something reasonably small, e.g. how to loop through an array in JavaScript, then searching on the internet will likely give you a high-quality answer. If your problem is something quite large, e.g. how to build an authentication endpoint using Express and MySQL, it's very likely that (1) you won't find a solution specific to your needs, and/or (2) the solution(s) you do find are not high-quality. If you cannot find or derive a high-quality solution from the internet, it might be worth asking for help.
Are you hardstuck? If you've tried searching on the internet to no avail, it might be worth asking for help.
Are you working in unknown territory? If you're working on anything that you're unsure of, it's usually a good idea to ask a more senior developer to sense-check your work, just to make sure you're on the right page.

The best junior programmers I've worked with are always the ones who are not afraid to reach out to their senior colleagues for advice, and the best senior developers I've worked with were always willing to mentor their junior colleagues. Any half-decent developer should be willing to help you, so don't be afraid to reach out! However, make sure that your question is specific and shows research effort.

"If you do not know how to ask the right question, you discover nothing."

– W. Edwards Deming

Thanks for reading! What do you guys think?

How to deal with stubborn employees. (as a senior developer)

Benjamin Liu — Sun, 24 Nov 2019 03:55:21 +0000

Everyone knows someone stubborn.

If you don't, I have some bad news for you. :)

Regardless of how wrong or right you think you are, if you're not willing to acknowledge others' opinions and compromise as appropriate, you're going to have a hard time getting things done.

"Talent wins games, but teamwork and intelligence wins championships."

– Michael Jordan

As a senior developer / manager, you might have to deal with stubborn employees, or you might be the stubborn one. Either way, not properly addressing the issue can greatly affect your team dynamic.

Let's look at this scenario:

You are the team lead at a company, and Jerry is a hardworking frontend developer that has been working at this company for 10 years. Recently, the company hired a senior frontend developer to take lead of the development process. As time goes on, Jerry becomes increasingly passive-aggressive, thinking that he is more suited for the job than this senior developer. He now refuses to listen to anyone in his team except the team lead, causing a lot of development blocks and causing many workflow issues.

As the team lead, you realise that if this continues to drag on, this will be very detrimental to the entire team. So you decide to come up with a plan to deal with this type of behaviour.

Although it may be tempting to call Jerry out in front of the whole team for his attitude, this may cause more problems than it solves.

At the end of the day, Jerry is still a human being, and human beings have feelings. It's not in your best interest to bring others down like that.

Instead, consider:

Conducting code reviews within a team meeting or group setting where you (as the team lead) are present. This may help to keep his attitude in-check, whilst also ensuring that necessary quality control is completed.
Orchestrating pair programming sessions to further encourage teamwork. This may help the issue and associated resentment to organically dissolve.
Talking to Jerry personally, and asking him if something's bothering him. In many cases, it is a combination of various issues and factors that causes behavioural symptoms, and where the employee is willing to discuss and open up, this can be a suitable method of encouragement and counselling.

Feedback is very important, and it is important that employees correctly perceive their role within the team. In the case of Jerry, by respecting emotional/professional boundaries whilst also being firm on code quality and delivery, you will slowly gain the respect of all your employees, including Jerry.

Thanks for reading! What do you guys think? How would you handle this kind of situation?

Wait, but what exactly is React?

Benjamin Liu — Fri, 22 Nov 2019 03:37:57 +0000

Coworkers and colleagues have been asking me about React since 2014. Instead of explaining it time and time again, I will give my 5-minute summary here in this article.

What is React?

React is a JavaScript library developed by Jordan Walke, a software engineer at Facebook back in 2011. Since then, React has become a widely popular open-source library that is used by Facebook, Instagram, Netflix, PayPal (just to name a few) and maintained by Facebook, Instagram and an amazing community of developers that have taken an interest in the library.

How does React work?

React uses a component based architecture (i.e. it involves you writing "components"), defined using a special JSX syntax which compiles down into regular JavaScript. Here we have a Button component that renders a different class name to the <button> based on the props.

const Button = props => {
  const className = `button ${props.type}`;

  return (
    <button className={className} onClick={props.handleClick}>
      {props.label}
    </button>
  );
};

This level of flexibility makes creating interactive UIs fun as you are able to reuse components in different parts of your webpage.

Note: Although the code within the return looks like valid HTML, it JSX - a syntax extension to JavaScript to make defining React elements easier.

When you want to render a particular kind of button, you just pass the <Button> component a list of props (similar to attributes in HTML):

<div className="app">
  <Button handleClick={handleAPICall} label="Submit" type="primary" />
</div>

Why should I learn React?

It's incredibly popular, and as such is very employable. A survey conducted by Stack Overflow showed that React was the most loved and wanted web framework.
It's incredibly fun. IMHO what makes React so great and so popular is the fact that it is not restrictive. It does so much yet has so few constraints, that using it feels just like magic.
Do you have another reason? Let's discuss it below in the comments! Thanks for reading!

Don’t excessively mutate the DOM. Here’s what you should do instead.

Benjamin Liu — Wed, 20 Nov 2019 11:26:22 +0000

Before I continue I just want to say that it’s not bad practice to target the DOM. Without targeting the DOM, JavaScript wouldn’t be able to manipulate anything on your page, rendering it useless as a frontend programming language.

However, you do want to stay cautious and be very careful about when and where you’re targeting the DOM, as certain operations may noticeably affect the performance of your webpage.

Now with that said, you might be asking yourself:

"How bad can directly manipulating the DOM really get?"

REALLY REALLY MESSY especially if you're working in a team, you're adding unnecessary levels of complexity which can result to potential bugs whether it'd be from performance, testing and even refactoring.

Take this bit of code for example:

for (let i = 0; i < 10000; i++) {
  const p = document.createElement("p");
  document.body.appendChild(p);
}

We're generating 10,000 <p> tags and appending each one to the <body> of the DOM. This is highly inefficient as this code tells the DOM to update and figure out where everything goes again for 10,000 times.

A cleaner approach:

const fragment = document.createDocumentFragment();
for (let i = 0; i < 10000; i++) {
    const p = document.createElement("p");
    fragment.appendChild(p);
}
document.body.appendChild(fragment);

By grouping all our elements so that we append them all together we are able to drastically reduce the amount of times that the DOM needs to be modified down to one. This also reduced the total running time from 413.125ms to 12.189ms.

Fun Fact: React.js provides a VirtualDOM that creates a lightweight copy of the DOM which it keeps track of. React also tries to update the DOM as little as possible by grouping together changes.

Thanks for reading!

The window, the mirror, and how a little bit of introspection can go a long way

Benjamin Liu — Mon, 18 Nov 2019 09:59:57 +0000

Picture this:

Your team deployed the company's flagship project just 2 hours before the investor meeting. Now the demo's started - no more last-minute changes are possible. The only thing piercing the silence is the steady drip-drip of a leaky faucet on the floor above. Everyone is trying their best to eavesdrop in on the conversation going on in the conference room, where the CEO is demonstrating the project to the group of investors.

"Oops - that wasn't supposed to happen."

Your heart sinks. The demo just went horribly wrong. As the team lead, you know that this whole thing was ultimately your responsibility.

Now in this moment, you can do one of two things:

You can blame it on Jerry. Yes, it must be Jerry's fault! In fact, we have clear evidence that Jerry wrote the code that ended up breaking. Yes, it must be Jerry's fault! (Note: poor Jerry is a metaphor for literally anyone else on your team.)
You can take the blame and handle it gracefully. Either way, the company has lost a huge opportunity, and as the team lead you are responsible for the project. Best not to let the resentment and guilt seep any further down.

You decide to go with option 2.

"Yes, it was me. I should've had the foresight to include additional testing as part of our last sprint, and I failed to do that. I'm sorry."

Your team sits in silence as the CEO continues to rant for what seemed like an eternity.

In the next sprint the following Monday, just as you were about to speak, Jerry interjects:

"I just wanted to say thanks for taking the blame on behalf of the team. I know that it was my code that broke, and I apologise. I've already added that issue as a bug onto our issues board."

Others in the team chime in too:

"Yeah, what you did was really brave and totally undeserved."

"Thanks for sticking up for us."

Imagine a window and a mirror on the wall in front of you.

When something goes wrong, a bad leader would look out the window and blame the people out there - their own team, staff from other teams, third parties - anyone but themselves. However, a good leader would look into the mirror and try to identify their own problems, and how they improve.

When something goes right, a bad leader would look into the mirror and praise themselves - their leadership skills, their technical prowess, their networking ability. On the other hand, a good leader would look out the window, and share the praise amongst the team.

"Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work."

– Vince Lombardi

Thanks for reading! What do you guys think?