DEV Community: Chak Shun Yu

How To Create More Intuitive Styling Using CSS border-box Box Model

Chak Shun Yu — Fri, 22 Apr 2022 07:56:49 +0000

One of the most controversial aspects of frontend development is styling. Whether you’re using React, Angular, Vue, Svelte, or any other frontend library, you either hate it or love it. But regardless of how much or little you enjoy the CSS part of your frontend development, it’s an unavoidable one.

Personally, I found that the CSS box model is one of the most straightforward but at the same time complicated concepts to work with. In theory, it’s responsible for the width and height of an element and there are only 4 things that you need to consider for it: the content area, the paddings, the border, and the margins. But in practice, it can be difficult to make all of these 4 aspects work intuitively together in a way that results in flexible and responsive user interfaces.

Some people would even argue that it can be quite overwhelming at times. And I was one of them.

The Default `content-box` Box Model

In CSS, the box model of an element can be changed using the box-sizing rule. There are only two options and by default, the box model is set to content-box. In this box model, the width and the height that are set onto the element only apply to the content area of the element.

Let’s say we have an element with a width of 400 pixels and a height of 300 pixels. But due to design reasons, it should now also include paddings (15px), a border (30px), and margins (10px). After setting those CSS rules, the element is now no longer just 400 by 300 pixels. This is due to the content-box box model. Instead, only the content of the element will be 400 by 300 pixels. The entire element will be 490 pixels wide (400 + (15 + 30) * 2) and 390 pixels high (300 + (15 + 30) * 2)).

Although this is the default and most people will be adjusted to this model, it feels counterintuitive to me. The problem that I experience with this box model is that it treats the border and padding differently than how my mental model does it. Instead of considering the dimensions of elements based on solely their content, I think about them as a whole including the padding and borders.

For me, this made the process of sizing elements quite tedious. You would have to start on the inside with the content, go outwards for the entire element to include the border and padding, and then backtrack inwards again to calculate the different sizes.

The `border-box` Box Model

This is where the other box model option comes in, border-box. Instead of only considering the content area of an element for its width and height, this box model takes all of the content area, the paddings, and the border into account.

So using the previous example, the entire element itself would still remain 400 pixels wide and 300 pixels high. Instead of adding the padding and border outside of these dimensions, they’re added on the inside. So the content would ultimately be 310 (400 - (15 + 30) * 2) pixels wide and 210 (300 - (15 - 30) * 2) pixels high.

This made things a lot more sense to me and allowed me to create styling that felt more intuitive. Now, if I provided an element with certain dimensions, it would be guaranteed that the element would still be sized according to those specifications. While the content-box box model reasons about the size of UI on the level of its content, the border-box box model does it on the level of the entire element.

(Try it here in this CodeSandbox)

If you liked this article, consider checking out the other entries in the Uncommon React newsletter or my Twitter for future updates. If you like my content in general, you could consider sponsoring me with a coffee to keep me going.

Multiline Text Truncation With CSS line-clamp

Chak Shun Yu — Fri, 22 Apr 2022 07:54:53 +0000

In frontend development, React included, it’s common to have to truncate text that is presented to the user. There exist plenty of reasons to do so. It could be to save precious screen estate, to make different parts of the UI appear uniform, to put less important information to the user behind a toggle, and the list goes on.

Most frontend developers will know how to implement text truncation for a single line of text. It requires a set width and using a mix of the overflow: hidden, white-space: nowrap, and text-overflow: ellipsis CSS rules. All of these together will make the text truncate after one line and add an ellipsis at the end of the text if the last CSS rule was applied.

But that only works for single-line text truncation. In certain scenarios, it’s beneficial for the UI to truncate a text after multiple lines instead of just one. Compared to single-line text truncation, the same reasons to do so also apply but in a slightly different form. But how can you implement this?

Workaround Methods

For a long time, unfortunately, there was no easy way to implement multiline text truncation. All of the solutions would revolve around either counting words, counting letters, or putting the content inside a box with certain dimensions. But all of those solutions were clunky, inflexible, and suffered from their own problems.

Counting words and letters both require you to make use of JavaScript, which is less optimised for the browser compared to CSS solutions. Counting words is extremely dependent on the language and the length of the words, which can still result in uneven truncation while counting letters can result in broken words for the user. Both solutions also require the content to be entirely textual.

On the contrary, putting the content inside a box with specified dimensions is a CSS based solution. The problem with the single line truncation solution is that it requires text wrapping to stop after one line. This solution avoids that CSS rule and, instead, creates a box around the content based on the text’s spacing and line-height. However, this solution is very coupled to the content’s font properties and makes it extremely inflexible.

CSS’s line-clamp

To solve all of these issues, a CSS rule was added to WebKit: -webkit-line-clamp. It accepts an integer value and limits the content of the element it’s used on to the specified number of lines. The requirements for using this line clamping feature are that the line clamped element should have its display property set to either -webkit-box or -webkit-inline-box, and that the -webkit-box-orient property is set to the vertical value. That would look something as follows.

.content {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow: hidden;
}

What happens is that CSS will render all the content, but limit it after the specified number of lines (in this case, 3). At the end of that line, it will then add ellipses to indicate the line clamping. Lastly, you’ll have to add the overflow: hidden CSS rule to make sure all the other lines are not visible.

And there you go, now you have uniform elements that are always truncated to the same amount of lines. And all of this was done through pure CSS.

(Try it out in this CodeSandbox)

The last thing to mention is browser support. Browser support for these handy CSS rules has always been one of their biggest downsides. While there are a lot of neat and useful CSS rules out there, they’re often limited to certain web browser engines or web browsers. This makes it difficult to adopt them as they would only cover parts of the user base.

In the case of line-clamp, it’s a CSS rule that has been specifically been implemented in WebKit. However, at the time of writing this article, the support for -webkit-line-clamp has reached almost all of the major browsers. The only browser that doesn’t support it is Internet Explorer, which could impose issues if it’s a significant part of your user’s browser demographic. However, line-clamp is part of the CSS Overflow Module Level 3 which could provide more widespread support in the future.

Summary

Multiline text truncation is a common frontend issue to encounter, frequently used to make content more uniform, save screen estate, or reduce the amount of less important information on the screen for users.

While the single-line equivalent issue can easily be solved with a few intuitive lines of CSS, the same didn’t apply for multiline text truncation. Instead, frontend developers had to resort to methods like counting words, counting letters, or defining the dimensional box of the content themselves. Ultimately, all of these methods are suboptimal, inflexible, and suffer from their own respective issues.

But with the implementation of the line clamping feature in WebKit, all of the issues with the workaround issues were resolved. It provided us with a set of straightforward CSS rules that could be used to implement multiline text truncation through pure CSS. While -webkit-line-clamp and its companions are not yet supported by the entire field, it’s already available in most of the major browsers for you to use.

A Fundamental Guide To React Suspense

Chak Shun Yu — Tue, 08 Mar 2022 10:04:42 +0000

Another big feature that will be released in React 18 is Suspense. If you’ve been in the React development field for a longer time, then you’ll know that the Suspense feature isn’t particularly new. Back in 2018, Suspense was released as an experimental feature as part of the React version 16.6. Then, it was mainly targeted towards handling code splitting in combination with React.lazy.

But now, with React 18, the official release of Suspense is in front of us. Together with the release of concurrent rendering, the real power of Suspense is finally unlocked. The interactions between Suspense and concurrent rendering open up an enormous world of opportunities to improve user experience.

But just like with all features, just like concurrent rendering, it’s important to start with the fundamentals. What is Suspense exactly? Why do we need Suspense in the first place? How does Suspense solve that problem? What are the benefits? To help you with understanding these fundamentals, this article will go over exactly those questions and provide you with a solid foundation of knowledge regarding the topic of Suspense.

What is Suspense?

In essence, Suspense is a mechanism for React developers to indicate towards React that a component is waiting for data to be ready. React then knows that it should wait for that data to be fetched. In the meanwhile, a fallback will be shown to the user and React will continue with rendering the rest of the application. After the data is ready, React will come back to that particular UI and update it accordingly.

Fundamentally, this doesn’t sound too different from the current way in which React developers have to implement data fetching flows: using some kind of state to indicate whether a component is still waiting for data, an useEffect that starts data fetching, showing a loading state based on the data’s status, and updating the UI after data is ready.

But in practice, Suspense makes this happen in a technically totally different. Contrary to the mentioned data fetching flow, Suspense deeply integrates with React, allows developers to more intuitively orchestrate loading states, and avoids race conditions. To gain a better understanding of those details, it’s important to know why we need Suspense.

Why do we need Suspense?

Without Suspense, there are two main approaches towards implementing data fetching flows: fetch-on-render and fetch-then-render. However, there are some issues with those traditional data fetching flows. To understand Suspense, we have to dive into the problems and limitations of those flows.

Fetch-on-render

Most people will implement data fetching flows as mentioned before, using useEffect and state variables. This means that data only begins fetching when a component renders. All the data fetching happens in components’ effects and lifecycle methods.

The main issue with this method, where components only trigger data fetching on render, is that the async nature forces components to have to wait for the data requests of other components.

Let’s say we have a component ComponentA that fetches some data and has a loading state. Internally, ComponentA also renders another component ComponentB, which also performs some data fetching on its own. But due to the way data fetching is implemented, ComponentB only starts fetching its data when it’s rendered. This means that it has to wait until ComponentA is done fetching its data and then renders ComponentB.

This results in a waterfall approach where the data fetching between components happen sequentially, which essentially means they’re blocking each other.

function ComponentA() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchAwesomeData().then(data => setData(data));
  }, []);

  if (user === null) {
    return <p>Loading data...</p>;
  }

  return (
    <>
      <h1>{data.title}</h1>
      <ComponentB />
    </>
  );
}

function ComponentB() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchGreatData().then(data => setData(data));
  }, []);

  return data === null ? <h2>Loading data...</h2> : <SomeComponent data={data} />;
}

Fetch-then-render

To prevent this sequential blocking of data fetching between components, an alternative would be to start all the data fetching as early as possible. So, instead of having components be responsible for handling the data fetching on render and data requests all happen separately, all the requests are initiated before the tree starts rendering.

The advantage of this method is that all data requests are initiated together, and thus ComponentB doesn’t have to wait for ComponentA to be done. This solves the issue of components sequentially blocking each other’s data flows. However, it introduces another issue that we have to wait for all data requests to be finished before anything is rendered for the user. As can be imagined, this is not an optimal experience.

// Start fetching before rendering the entire tree
function fetchAllData() {
  return Promise.all([
        fetchAwesomeData(),
        fetchGreatData()
  ]).then(([awesomeData, greatData]) => ({
    awesomeData,
        greatData
  }))
}

const promise = fetchAllData();

function ComponentA() {
  const [awesomeData, setAwesomeData] = useState(null);
  const [greatData, setGreatData] = useState(null);

  useEffect(() => {
    promise.then(({ awesomeData, greatData }) => {
      setAwesomeData(awesomeData);
      setGreatData(greatData);
    });
  }, []);

  if (user === null) {
    return <p>Loading data...</p>;
  }

  return (
    <>
      <h1>{data.title}</h1>
      <ComponentB />
    </>
  );
}

function ComponentB({data}) {
  return data === null ? <h2>Loading data...</h2> : <SomeComponent data={data} />;
}

How does Suspense solve the data fetching issues?

In essence, the main issue with fetch-on-render and fetch-then-render boils down to the fact that we’re trying to forcefully synchronise two different flows, namely the data fetching flow and the React lifecycle. With Suspense, we arrive at a different kind of data fetching approach, the so-called render-as-you-fetch method.

const specialSuspenseResource = fetchAllDataSuspense();

function App() {
  return (
    <Suspense fallback={<h1>Loading data...</h1>}>
      <ComponentA />
      <Suspense fallback={<h2>Loading data...</h2>}>
        <ComponentB />
      </Suspense>
    </Suspense>
  );
}

function ComponentA() {
  const data = specialSuspenseResource.awesomeData.read();
  return <h1>{data.title}</h1>;
}

function ComponentB() {
    const data = specialSuspenseResource.greatData.read();
  return <SomeComponent data={data} />;
}

The difference with the previous implementations is that it allows components to initiate data fetching the moment React reaches it. This happens even before the component renders and React doesn’t stop there. It then keeps evaluating the subtree of the component and continues trying to render it while waiting for data fetching to be done.

This means that Suspense doesn’t block rendering, which means that subcomponents don’t have to wait for parent components to finish before initiating their data fetching requests. React tries to render as much as possible, all while initiating the appropriate data fetching requests. After a request finishes, React will revisit the corresponding component and update the UI accordingly using the freshly received data.

What are the benefits of Suspense?

There are a lot of benefits that come with Suspense, especially for the user experience. But some of the benefits also cover the developer experience.

Initiate fetching early. The biggest and most straightforward benefit of the render-as-you-fetch method that Suspense introduces is the fact that data fetching is initiated as early as possible. This means that users have to wait less and that the application is faster, which are universally beneficial to any frontend application.
More intuitive loading states. With Suspense, components don’t have to include a huge mess of if statements or separately keep track of states anymore to implement loading states. Instead, loading states are integrated into the component itself that it belongs to. This makes the component more intuitive, by keeping the loading code close to the related code, and more reusable, as loading states are included in the component.
Avoids race conditions. One of the issues with existing data fetching implementations that I didn’t cover in-depth in this article are race conditions. In certain scenarios, the traditional fetch-on-render and fetch-then-render implementations could lead to race conditions depending on different factors like timing, user input, and parameterised data requests. The main underlying issue is that we’re trying to forcefully synchronise two different processes, React’s and data fetching. But with Suspense, this is done more gracefully and integrated, which avoids the mentioned issues.
More integrated error handling. Using Suspense, we’ve basically created boundaries for data request flows. On top of that, because Suspense makes it integrate more intuitive with the component’s code, it allows React developers to also implement more integrated error handling for both the React code and data requests.

Final Thoughts

React Suspense has been on the radar for more than 3 years. But with React 18, the official release is becoming increasingly close. Next to concurrent rendering, it will be one of the biggest features that will be released as part of this React release. On its own, it could elevate data fetching and loading state implementation towards a new level of intuitiveness and elegance.

To help you understand the fundamentals of Suspense, this article covered several questions and aspects that are important to it. This involved going over what Suspense is, why we needed something like Suspense in the first place, how it solves certain data fetching issues and all the benefits that come with Suspense.

An Introductory Guide To Concurrent Rendering

Chak Shun Yu — Sun, 20 Feb 2022 20:11:34 +0000

The hottest topic in the React field right now is the React 18 release. In particular, the release will introduce a set of so-called concurrent rendering features. These features allow developers to opt into the concurrent rendering mechanism from React. This mechanism opens up an entirely new world of opportunities for React developers to control and optimise the experience of end-users. It is definitely one of the most exciting things we’ll receive in the world of React since hooks.

Because of this, it’s very likely that you’ve heard about concurrent rendering before. Maybe articles about it, the APIs around it, or what React 18 will bring to the table for it. However, you might be left wondering about the fundamentals of concurrent rendering. What is concurrent rendering exactly and why do we actually need it?

To help you with understanding the fundamentals, this article will go over those questions. By looking into its purpose, what problem it attempts to solve, and how it solves it, you’ll gain a solid foundation of knowledge regarding the topic of concurrent rendering.

Why do we need concurrent rendering?

One of the issues with React in its current form is that all state updates are synchronous. This means that React is only able to handle them one by one. In a lot of use cases and real-life scenarios, this is perfectly fine and won’t impose any limitations on the user experience.

But in scenarios where React would like to pick up a different state update than the one it’s currently working on, that’s plainly impossible right now. React is not able to interrupt, pause, or drop rendering an update after it has started — it’s a blocked process.

In essence, this puts an upper limitation on the process of optimising user experience. Although it’s a very high one, there still exists a limit. Every state update is treated as equally important, even if that doesn’t hold for the user experience. Certain updates can have more priority or urgency than others. Not being able to do so actually negatively impacts the user experience tremendously compared to what it could be, which is suboptimal.

What is concurrent rendering?

This is exactly where concurrent rendering comes in. Concurrent rendering is a set of features that allow your React project to opt into so-called interruptible rendering. Contrary to the previous rendering process where React was blocked, this makes the rendering process interruptible from React’s side.

This opens up a lot of new possibilities for React developers to further enhance the user experience of React applications.

It allows React to handle multiple state updates at once. However, it doesn’t mean that React will suddenly perform all the queued state updates simultaneously at once. Rather, opting into concurrent rendering allows React to think about its best course of action. Fortunately, it’s also something that we as developers can control.

Let’s say React is currently working on a state update and a different one comes in, then React can make different decisions based on a variable of factors. If the new incoming state update is marked as equally or less urgent, then nothing will change compared to the previous rendering process. React will proceed with the current state update like normal. After it finishes, it’ll pick up the new state update.

But if the new incoming state update is marked as more urgent, then React can decide to pause the current state update and handle the incoming one first. After finishing the new and more urgent state update, React will then go back to the original state update. If it determines that it’s necessary to resume it, it’ll do so. If it turns out that the state update is now irrelevant, it can decide to drop it altogether.

What’s Next

This article briefly covered one of the most exciting features that React 18 will bring to the React development field, namely concurrent rendering, and get you up to speed with the entire topic. using the knowledge in this article, you should know what concurrent rendering is, understand what problem it attempts to fix, and have an overview of how it works.

Luckily, concurrent rendering doesn’t stop here. While there are so much more aspects to concurrent rendering to understand or dive into, this article serves as an introduction to get into the whole topic and allows you to further explore React 18 starting from here.

To give you some pointers:

This previous article of mine goes over the three new APIs that were introduced in React 18. All of them are hooks that allow certain developers to opt into concurrent rendering in certain scenarios.
The official React 18 announcement is a great place to find out more about React 18, different features, how to adopt it, and in general everything you need to know about the upcoming React release.
The React working group repository is a great place to learn more about the technical aspects, receive even more pointers, learn about the thought processes behind different APIs and features, and in general get a more in-depth perspective of everything in React 18.

That’s all there is! Now that you have a solid grasp on the topic of concurrent rendering, a whole new world opens up for you to explore in React 18. Go out there, explore, and enjoy this new adventure!

5 Reasons React Is Still Worth It To Pick Up In 2022

Chak Shun Yu — Mon, 07 Feb 2022 09:53:54 +0000

If you have anything to do with frontend development, then it’s almost a given that you’ve heard about React. No matter if you’re trying to get into front-end development, expand your front-end development knowledge, or follow the latest news in the field, it’s unavoidable to not avoid React.

The React field is extremely big, grows by the day, and definitely isn’t shrinking anytime soon. But UI JavaScript is infamous for having a short lifespan. Therefore, all of these factors together always raise the topic of whether it’s still worth it to pick up React at any given moment.

Maybe it’s already too late. Maybe React has already passed its peak. Maybe its popularity and demand will drop now. Maybe the community will move on to something else. Those are legitimate concerns before learning any JavaScript UI library.

However, I personally think that if you haven’t picked up React yet and am not sure yet, there are also still legitimate reasons to do so. This article will share these reasons why I think React is still worth it to pick up in 2022.

Still Extremely Popular

Although Svelte took over the number one spot as the JavaScript library with the highest satisfaction and interest in the state of JavaScript survey in 2020, React is by no means a dead library. Looking at different metrics, like Github stars, library usage, NPM trends, most used web framework, React as a frontend library is still by far a frontrunner in the field compared to the likes of Vue, Angular, and Svelte.

High Job Demand

All of that popularity also transfers into a high job demand. In 2021, job openings looking for React developers were by far the highest amount compared to other frontend libraries. Compared to jQuery, Angular, and Vue, there were respectively approximately 3.5, 4, and 7 times more job openings for React experience.

Even right now, that trend isn’t looking to change any time soon. Doing a quick search of LinkedIn job openings yields an enormous amount for React developers. If you’re thinking about picking up React but are concerned about job opportunity and safety, then there really isn’t a lot to worry about in the foreseeable future.

Large Active Community

One of the most important aspects of the survivability of a library is its community. Without a large or active community, you’ll be left to solve problems on your own when you encounter them. Especially for people looking to pick up a library, such a thing can be extremely demotivating and even cause them to drop using it altogether.

Fortunately, React has an extremely large and active community. There are active communities on Stack Overflow, Quora, Medium, Dev.to, several newsletters, too many NPM libraries to count, and many more. For almost any question, problem, or implementation idea related to React, it’s very likely that someone has wondered the same before and that you’ll be able to find something about it in one or multiple of the communities.

Strong Ecosystem

Building forth on a large and active community is the existence of a strong ecosystem around React development. NPM libraries were already mentioned and it’s likely that there’s a library for almost anything you can imagine in React.

But on top of that, the community has formed an extremely strong ecosystem around React in the form of tools and frameworks. There are tools like Storybook that help you with consistent component design and development, libraries like styled-components and Emotion that’ll help you with styling, and even frameworks that will provide you with the entire package like Next.js, Gatsby, and the all-new Remix.

Still More To Come

Despite React being around for so long, it doesn’t look like the field will stop having new stuff anytime soon. Even in 2022, there are still a lot of things to look out for. React 18 alone will be one of the biggest React releases of all time. Not only will it ship features like concurrent rendering, but it’ll also shift a large focus to server-side rendering.

The great thing is that this is only a fraction of the things we’re guaranteed to get in 2022. Who knows what else the year will hold for the React development field. But no matter whether you’re already an experienced React developer or still learning the basics, there are still a lot of exciting things on the horizon for you.

Final Thoughts

It’s always difficult to decide whether a certain frontend framework or library is worth it to pick up. There are so many choices and the field changes on a frequent basis. But even in 2022, there are still plentiful reasons to hop onto the React train if you haven’t already.

After so many years of being at the top, React as a library is still extremely popular. Because of this, the job demand for React developers is still extremely high, there is a large and active community, and the field has established a strong ecosystem around it. On top of that, there’s still so much more to come this year.

Even if React might not end up being the best choice, as of right now, it’s very unlikely a bad choice.

Top React Development Trends for 2022

Chak Shun Yu — Tue, 01 Feb 2022 22:26:54 +0000

The year 2022 has just started and there are a lot of exciting things on the radar if you’re a React developer. Whether it is things that are already released or that still have to come, there are a lot of things to look forward to. It definitely won’t be a boring year in the world of React development and I’m personally speaking more than excited for everything we know that 2022 will for sure bring. This article will go over these topics that I think will either make a big impact on the field of React development or concepts that every React developer should look out for this year.

Remix

Teased for a very long time, Remix was finally officially open-sourced at the end of 2021. Supported by some of the greatest names that the field has to offer, Remix markets itself as a self-proclaimed full-stack web framework based on web fundamentals with a modern user experience as a focus.

At the core of Remix stand concepts like performance, progressive enhancement, nested routes, parallel data loading, customizable levels of error handling, and per-route CSS loading and unloading. For any frontend developer, Remix will be like a box of chocolates waiting to be unpacked. And 2022 will be the year for that.

To learn more about Remix or to get started with it, I recommend checking out their v1 blog announcement that will point you in all the good directions.

Server-Side Rendering

One of the most exciting things on the way in the realm of React is React 18. It includes tons of new features, APIs, and much more. But one of the most important aspects is the added focus on server-side rendering and all the out-of-the-box possibilities.

Although it’s already possible to have server-side rendering using different frameworks like Next.js and Gatsby, the out-of-the-box support from React’s side has always been limited. But with the addition of features like Suspense, HTML streaming, and selective hydration, a world of opportunities will open up.

The length of this paragraph is definitely not reflective of how excited I am about this, but diving deeper into this topic will warrant an entire article on its own. If you’re not sure about what server-side rendering means, what the difference is with client-side rendering, or what the above features mean, now is the time to investigate them in preparation for React 18!

Concurrent Rendering

If you thought that there would only be one big topic as part of React 18, then the React team has a very pleasant surprise for you. Another very exciting feature coming in the next version of React is the so-called concurrent rendering mechanism.

To give you a very brief summary of what concurrent rendering is: one of the issues with React in its current form is that all state updates are synchronous. This means that React has to handle them one by one, finishing the current one before being able to pick up a new one. For a lot of cases, this is perfectly fine. But when certain updates have more priority or urgency than others, this can become a problem.

This is where concurrent rendering comes in. It allows React to handle multiple updates at once. However, this doesn’t mean that React will perform several state updates at once. Rather, it can decide to pause the current state update that it’s working on and pick up a different one that is more urgent. Later, React can decide to resume the paused state update or drop it altogether.

Honestly speaking, this is by far the thing that I’m looking forward to the most in 2022. Concurrent rendering opens up an entirely new world of possibilities for React developers to improve the real and perceived performance of their frontend applications. It allows us to approach React in a totally different way and forces us to change the way we currently think about rendering flows.

To learn more about anything related to concurrent rendering, I recommend checking out the React 18 announcement. It includes everything necessary to get started with understanding concurrent rendering, like the concepts behind it and how to opt into it. In fact, concurrent rendering is not a single feature but will come as a set of APIs that will allow React developers to opt different parts of their application into concurrent rendering.

Behaviour Testing

In the field of React, we have seen a significant shift in the way components are tested over the past years. While previously it was mainly focused on unit tests, the current focus is more orientated towards making sure your tests are as representative as possible of the experience of your users — behaviour testing.

Right now, behaviour testing has become the industry standard for testing in React development. With an ever-increasing adoption rate, the popularity of React Testing Library, and even being mentioned in the official React documentation, it’s unlikely that behaviour testing will leave the scene soon.

Even if you’re not using React Testing Library, it’s possible to adopt behaviour testing as a concept. In practice, behaviour testing is not tied to any framework or library. With the proper approach and thoughtfulness, you’ll be able to write behaviour tests using Enzyme, Jest, Mocha, and so on. As a React developer, implementing proper behaviour testing will be an invaluable and essential tool in your skillset.

Honourable Mentions

While the above-mentioned topics are very exciting, big, and relatively unknown topics for a lot of React developers, there are also a few others that deserve honourable mention. These technologies are still very worthwhile to look out for in 2022 but have been on the scene for quite some time already. Therefore, the chances are higher that you’ll have encountered them or worked with them if you’ve been in the React development field.

No list of React topics would be complete without including TypeScript. As one of React’s most iconic partners, it’s very difficult nowadays to imagine any medium-sized or larger React project existing without it. The differences between a React project with TypeScript and without are significant. Not only does it remove an enormous amount of ambiguity from JavaScript, but it also tremendously impacts the maintainability, scalability, safety, and organisation of the code project. If you haven’t added TypeScript to your skillset as a React developer, then 2022 is definitely the year to do so.

If you’ve done React development for a long time already, it’s likely that you’ve heard about the terms “design system” or “component-driven development. And if you’ve ever looked into either of those, it’s extremely likely that you’ve come across Storybook. The open-source tool has become a staple for structured and reusable UI development. But even with its current popularity, the awesome team behind Storybook aren’t slowing down anytime soon. With active maintenance and mind-blowing features in every release, Storybook is a tool always worth looking into if you haven’t yet.

Final Thoughts

Even after so many years, the field of React development still has a lot to offer. Whether you’re a seasoned veteran or a newcomer to the game, there are always things to look out for in the world of React.

Looking ahead, I’m extremely excited for 2022 and everything it will bring to us in terms of new technologies and concepts. The introduction of Remix will really shake up the way we approach frontend development and the field of React frameworks. React 18 will make it so much easier to implement a staple part of web development in server-side rendering, while also introducing an entirely new way to optimize the performance of frontend applications in the form of concurrent rendering.

And if those weren’t enough to get you excited, there is also still an entire world to explore for behaviour testing as it’s cementing itself as a testing standard, TypeScript as an essential tool for maintaining React projects of any size, and Storybook as a core tool to fuel structured UI development and collaboration with design.

Do You Need To Master JavaScript Before Learning React?

Chak Shun Yu — Mon, 17 Jan 2022 20:49:40 +0000

One of the main concerns that I see at different platforms from developers learning React is the relationship between JavaScript knowledge and React. Most of them know that React is a JavaScript library and thus that they should have a certain level of knowledge about JavaScript. But they’re often uncertain about how much they should dive into JavaScript before turning towards React.

As someone who started learning React on his own more than 4 years ago and has been working as a React developer for the past 3 years, it’s a concern that I’m extremely familiar with. It’s a struggle that I had as well in the beginning. Although it worked out in the end, it definitely could’ve been a smoother process. Using that experience, this article will cover whether you should master JavaScript before learning React and how far you should take it.

The main concern that newcomers often have is that their mastery of JavaScript is limited and therefore they aren’t able to properly learn React.

It is certain that having prior knowledge and a proper understanding of JavaScript will help you pick up React quicker. Ultimately, React is just a UI library built on top of HTML/CSS/JavaScript, where JS is responsible for most of the logic. Knowing about concepts like variables, array functions, callbacks, scopes, closures, and other JS related topics will definitely benefit you. It will tremendously speed up the pace at which you’re able to study and learn React.

But, does that mean that you’re not able to study React without knowing those concepts?

I would say it’s definitely recommended to familiarise yourself with them. It will make your learning process considerably easier, but it’s by no means a necessity. If your goal is to pick up React, don’t wait with it until you think you’ve mastered all of JavaScript. Based on personal experience, it’s likely that that moment won’t happen. In the end, the only thing you will have achieved is learning JavaScript instead of React.

There are a lot of resources out there that will give you pointers towards the recommended JavaScript concepts and functions to learn before React. Take a look and familiarise yourself with them, but don’t spend years on it. Knowing that they exist should be enough for most of the cases. After that, start learning React.

Yes, there will be JavaScript topics that you don’t understand, but that’s fine. Since you already familiarised yourself with the most common JavaScript topics, you should be able to go through React without stopping for every JavaScript topic. You can look up the topics that you don’t understand and then learn about them on the fly. Doing it while learning React guarantees you that it’s relevant and increases the chances of it sticking.

But, should I learn everything about JavaScript then?

Not really. While knowing certain JavaScript concepts is beneficial, not every concept in JavaScript is also used in React. For example, I would say that it’s perfectly fine to not know about the details of this (if you’re not using class components) or how the prototype chain works. While they are crucial for proper JavaScript development, some topics will not be relevant on a day-to-day basis as a React developer.

Final Thoughts

People often try to over-prepare themselves. The same applies to learning new technologies, frameworks, or libraries. I’ve seen a lot of developers also do this with React, myself included when I started my journey into frontend development. Looking back at it, this article uses that experience to answer some of the biggest concerns about the relationship between JavaScript and learning React for newcomers.

React is a JavaScript-based UI library, there is no way around it. If you want to write React code, you’ll also have to write JavaScript code. Therefore, it’s recommended to learn a bit about JavaScript. But don’t overdo it. Create a foundation and move on to React. In the worse case, you can learn things on the fly. Ultimately, your goal is to learn React, not JavaScript.

If you liked this article, consider checking out the other entries in the Uncommon React newsletter or my Twitter for future updates. If you like my content, consider sponsoring me with a coffee to keep me going.

My Simple Checklist For Well Tested React Components

Chak Shun Yu — Sun, 03 Oct 2021 20:15:56 +0000

This article is part of Uncommon React, a newsletter focused on helping you become a better React developer by focusing on the less commonly discussed topics, like testing, readability, and more.

Testing is one of the most important activities in software development and React development is no exception to this. Unfortunately, software testing itself is a very overlooked and neglected topic. More often than not, implementing tests is an afterthought and developers are only willing to spend the least amount of time and effort on it. The results are low-quality tests that don't provide any confidence in our software, are meaningless, and are only introducing noise to the codebase.

Proper software testing is a very difficult topic, even more than software development itself. With software development, the beginning and the end are clearly defined. But for software testing, this is not the case. There is no clear path that you can take every time to test your code. It's different every time based on the feature, context, and implementation.

Over the years, I've had my fair share of struggles and difficulties with it. For a very long time, I was writing tests for the sake of writing tests. Just before opening a Merge Request (MR), I would remember that I had to write tests. I would mindlessly copy over the structure from other existing tests and adjust it towards my code. Minimal effort for maximum results, kind of.

The problem was that the resulting tests were far from decent quality, let alone good quality. So often did I think after shipping a feature that it was implemented and tested very well, but so often have bugs been reported in those features. The problem was that I always tested the wrong aspects, tested in the wrong context, or didn't know what to test specifically.

After taking this topic more serious, one of the habits that I've picked up is always going through a testing checklist of topics that I try to cover when testing React components. This article will share that testing checklist, elaborate on the topics, and can help you get through testing your React components easier, create a checklist of your own, and ensure higher quality React code.

User Interactions

The most important things to tests for React components are user interactions. In the end, React development is a form of web development. All the web applications that we create are intended to be used by customers, clients, and users. The most important aspect for all of these user audiences is the interactivity of the application. Without interactivity, the web application is a static website and will hold little value to its users.

When verifying user interactions, it's important to determine what the prerequisites, the specific interaction, and the expected behaviour are. That will be the bread-and-butter layout for most of your tests. First, you set up the test in an environment that can trigger the interaction. Then, you mimic the user interaction. Lastly, you verify that it leads to the expected behaviour.

Every part of this process is crucial in making sure that the tests are useful, meaningful, and reliable. Every scenario will require different answers and different implementations, especially in regards to how to verify the expected behaviour. There are also many ways to implements these kinds of tests, like unit, behaviour, or e2e tests, and different tools, like Enzyme, React Testing Library, Jest, Jasmine, and more. Going over all of these will be a book on its own, but for now, the most important aspect is to start documenting user interactions in tests.

Product Manager Requirements

After user interactions, the second most important aspect of any new feature is the requirements from the product manager. In the end, we're writing code and creating software for a particular audience. The party that is responsible for being in contact with that audience, hearing their voice, and managing users' requests is the product manager of your team.

Verifying their requirements are satisfied is equally, if not even more, important than possible user interactions. In the end, the product manager will have (hopefully) thought out every aspect there is to a feature and provide you with a list of requirements. The most straightforward way to translate those into tests is by creating a test for every single requirement.

Ultimately, the requirements are like a checklist for when your feature is completed. Turning those into tests doesn't only verify that they are satisfied, but also lays a foundation of stability, documentation, and confidence for future developers to maintain and work with it.

Internal Components And Utility Functions

Most of the time, our focus for testing is on the external users of our code like end-users, clients, or even product managers. Similarly, most of the topics in this article are also geared towards that audience type. But when writing code, there is another type of audience that we should consider, namely other developers.

When performing React development, not all the code will directly affect the application as is presented to the end-user. React development also involves code like internal components and utility functions which are created for other developers to use. But to use them properly, they need to understand them.

There are different ways to document the usage, input, and appropriate results of this internal code, but one of the best ways is using tests. Documenting internal components and utility functions in tests immediately gives an example of how to use them, provides information on what to provide to them, and what the expected behaviour is.

Backwards Compatibility Features

From a client's perspective, especially when your product is released regularly, backwards compatibility is an important aspect. In frontend development, we have a similar thing regarding the dependencies that we use. For the user, being able to upgrade towards newer versions of a dependency or application can be a crucial factor in deciding whether to upgrade, migrate and adopt or not.

Based on personal experience, I either didn't come across this particular topic a lot or just never paid attention to it. Until my most recent job where we're shipping widgets using React regularly. One of the most important topics of discussion is whether a new version contains breaking changes and is backwards compatible.

Having proper tests in place to verify your existing features is a great start and can go a long way in ensuring backwards compatibility. But in frontend development, backwards compatibility isn't always only about features and interactivity. Aspects like SEO, DOM structure, and CSS class names are also part of the conversation. For these, snapshot tests are a great tool to test them with.

Regressions

So often have I seen the following scenario play out: A bug was reported by support about a feature that we shipped in the past. After a developer picked it up, it turned out that the original developer forgot a specific edge case or one of the requirements. Not a big deal, so the currently responsible developer wrote a fix and shipped the new feature. One week later, a new bug was reported in the same feature. Turned out we caused a regression. We fixed it and shipped it. Another week later, rinse and repeat.

There are a lot of aspects that we can dive into in this scenario regarding testing. But the most important one, for now, is to make sure that the newly added code didn't break the old code in any way. If it did, it's called a regression. From personal experience, regressions are one of the biggest causes of frustration for developers, users, and everyone involved.

To prevent regressions, you first need to have solid tests for the previous code in place. To start with that, it's important to make always add a test that covers when introducing a new feature or fixing a bug. This makes sure that it will not regress in the future.

Final Thoughts

Testing React components is one of the most important and impactful activities in React development, but unfortunately also one of the most overlooked and neglected ones. During several years of working with React, I've had my fair share of struggles and difficulties with it. After looking into this issue seriously, it became apparent that one of the problems was that I never knew what to test or how to approach it. Contrary to development, I never had a proper routine for testing.

This article shared the checklist that I nowadays go through when testing React components to ensure high-quality tests and code. These include verifying product manager requirements, internal components and utility functions, backwards compatibility features, and making sure regressions don't happen. The specific tooling or tests that you should use will vary and depend on the use case, but the most important aspect is to consider these topics in the first place and create a routine for yourself.

If you liked this story, consider following me on Twitter to stay up to date with my work or checking out my newsletter Uncommon React.

Are Your Pull Requests Hard To Review? 5 Tips To Make Them Easier

Chak Shun Yu — Sat, 02 Oct 2021 18:50:33 +0000

Reviewing is a core process in software development. It is a form of communication between two parties with different purposes. As with any form of communication, they can always be improved upon and the reviewing process is not an exception. Both the code proposer and the code reviewer play their parts, but in this article, we’ll focus on the proposer.

For the developer that is proposing the code, the main goal is to pass all the checkmarks of the reviewer. Then, the code will be merged into the codebase and shipped to production somewhere in the (near) future. Ideally, the code proposer would like to get through this entire process with minimal feedback and few back-and-forths from the reviewer’s side.

To prevent this, we as developers oftentimes emphasize making our code better. The assumption is that when the quality and readability of our code is high enough, the resulting Pull Request (PR) will be easier to review. In turn, this should lead to the desired results of less feedback, back-and-forths, and time spent in the reviewing process.

However, how easy a PR is to review is not only dependent on the code that it’s proposing. A PR that contains extremely high quality and readable code can still be hard to review for other developers. That’s because the quality of a PR isn’t equal to the quality of the proposing code. More than that, there are a lot of aspects to a PR that are unrelated to the code but that can still affect how easy the PR is to review.

I’ve gone through an enormous amount of PRs during my career as a developer, from both the code proposer and reviewer’s side. As a code proposer, I’ve made countless ones that ended up being very difficult to review for my colleagues. But none of the issues was related to the code, but rather about the PR itself. On the other side, as a code reviewer, I’ve also experienced a lot of different things that colleagues didn’t do in their PRs that significantly affected my reviewing experience.

Based on this personal experience, this article will share 5 non-code related mistakes that developers make that leads to their PRs being hard to review. Using this information, you’ll be able to avoid these mistakes yourself. In turn, this will help you create easier to review PRs, spend less time in the reviewing process, get your work shipped to production quicker, and in general improve the quality of the review process inside the engineering team.

This article is an entry in Reviewtober, the October series in which we explore how to improve at the reviewing process as React developers. The other entries can be found at Uncommon React, a newsletter focused on helping you become a better React developer by focusing on the less commonly discussed topics, like testing, readability, and more.

Leaving Out Contextual Information

The most crucial information to any PR, even more, important than the code itself, is contextual information. Information like the purpose of the PR, the reason code has to be changed, what bug the current PR solves, and so on. Without these types of contextual information, it’s extremely hard or even impossible for other developers to properly review your code. It’s like asking your colleagues to verify whether a car is working properly without telling them that it’s a car, what a car is, or why the car was necessary, and only showing them the car.

So often have I created a PR and left out the contextual information. Either I thought the PR was already self-evident, too small to warrant a lot of information, that it was unnecessary, or I was just too lazy to add it. Although there were several times where I got away with this, it didn’t change the fact that my assumptions were wrong and that I neglected my reviewers.

Every PR introduces code changes with a reason, purpose, and context. Without contextual information, any code change would be purposeless and unnecessary. That’s why it’s extremely important to include them in the PR. All the contextual information around the code is what provides the reviewer with a foundational layer to look at your code and associate it with the actual real-life issue you’re trying to solve. In that sense, leaving out contextual information from your PR is equivalent to actively handicapping your reviewers.

Including Unrelated Changes

Whether it’s to fix a big, introduce a new feature, pay off technical debt, automate processes, or update documentation, there’s always a single purpose to your PR. When reviewing your code, the assumption is that all of the included code is contributing towards that single goal.

Therefore, the worse thing a code proposer can do is include code changes in the PR that are unrelated to that purpose. Not only does it add noise to the PR which can distract the reviewer, but it will also confuse the reviewer. From personal experience, I’ve learned that this happens no matter the size of the unrelated changes. No matter how small the noise is that you’re adding, in the end it’s still noise.

Under the above-mentioned assumption, the reviewer will try to relate every code change towards the specified goal. But if a part of the PR is not related to that goal, that process becomes extremely confusing. In the end, this will result in the reviewer either spending more time than necessary on understanding the PR, requiring more back-and-forts because of the unrelated changes, or not understanding the PR at all.

Letting The Reviewer Figure Out Everything Themselves

Smaller PRs have less code than larger ones which means that they’re easier to review, that’s a fact that we can’t get around. Unfortunately, not every PR can only touch 2 files and change 20 lines of code. There will be bigger PRs that will either cover a lot of different files, hundred to thousands of lines of code, or a mix of these. Naturally, these are harder to review.

But despite bigger PRs being harder to review, it’s not that we as code proposers can’t contribute towards making them easier to review. Even the slightest push in the right direction, some small instructions, or any comment from the code proposer would make a significant difference. Unfortunately, it’s something that’s frequently neglected, yielding all the consequences for the reviewers.

As code proposers, one of the worse things we can do to our reviewers is to provide them with a PR to review and let them figure out everything by themselves. Although the impact in smaller PRs is less noticeable, the effect is still present in PRs of all sizes. Not only does this create an unstructured and difficult situation for the code reviewer, but it also requires them to start from scratch. They have to actively go out of their way to understand your work without proper knowledge, go through it multiple times to figure out the best approach, and thus spend more time and effort than could’ve been necessary.

Have Meaningless Version Control History

The version control history can be one of the most impactful aspects of a PR. A properly maintained version control history can have a significant impact on how difficult the PR is to review. Especially in larger PRs, breaking up chunks of related code into individual commits can make the lives of code reviewers significantly easier. The more organised the history, the easier becomes for reviewers to understand and get through the code.

Unfortunately, I’ve experienced a lot of PRs of which the version control history was basically meaningless. Either it had one big commit, too many commits, too small, or commit messages were not descriptive enough. Especially when the life span of the PR exceeds multiple feedback rounds, but also in general, having proper version control history can make a world of difference.

There are a lot of aspects to maintaining proper version control history and can be a skill on its own. Examples of factors to include are the size of the commits (not too big, not too small), the number of commits (not too many, not too few), the commit messages, how to split the commits, and much more. It takes a lot of time and effort to do it well. But when you do it well, the effect can be felt tremendously by your code reviewers.

Rewriting Version Control History On Every Change

Building on top of the importance of version control history, there is also the stability of it. As the life span of a PR increases, so does the effect of properly maintained version control history on how difficult it’s to review. As PRs live for a longer time, the chances become increasingly higher that the code reviewer has to go through the PR several times. When reviewing multiple times, it’s rarely the case that the reviewer wants to go through all of the code on every review.

Rather, it’s common to resort to incremental reviews based on the added changes since the previous review. However, to do so the reviewer is dependent on the stability of the version control history. When reviewing subsequently, it’s necessary to know what part of the PR has stayed the same since their previous commit and what has changed.

Unfortunately, this is something that I’ve done a lot in the past. Every time I would have to process feedback or put additional changes on top of the existing PR, I would also conveniently rewrite the version control history. Either it was to amend the changes to a particular commit or to rebase the branch because it was convenient. The issue is that this obstructs the stability of the version control history and actively hinders how easy my reviewers could get through my PR.

Final Thoughts

There are two parties to a reviewing process, the code proposer and the reviewer. As code proposers, we want to pass all the checkmarks of the reviewer as easily as possible. To do so, we oftentimes focus on improving the code that we’re proposing in terms of quality, readability, and so on. But in reality, there’s more to a PR than just the code. Even if the code quality is perfect, the PR can still be difficult to review.

This article covered 5 non-code related mistakes that developer make that leads to their PRs becoming more difficult to review. These mistakes are leaving out contextual information, including unrelated changes that are irrelevant, letting the reviewer figure out everything by themselves without guidance, having meaningless version control history, and rewriting version control history on every change that you make to the PR.

A PR that is hard to review will take more time, more feedback, and more back-and-forths. You might think that it won’t affect you. But this means that your work will stall in the reviewing process even longer and it’ll take even more time before it gets into production. In the meanwhile, both your colleagues and you have to spend more time and effort on it.

In the end, it’s the entire engineering team that has to suffer.

How To Write Readable React Content States

Chak Shun Yu — Tue, 20 Jul 2021 10:16:28 +0000

Content is crucial to any React web application. It is what makes our applications live up, interactive for users, and really what makes it a web application over just a static website. For bigger React applications, it’s not uncommon to have ten to a hundred different content streams throughout. Because of this sheer volume, it’s important to implement them properly.

Every content stream has different states. The most common separation has 4 different categories, namely when the stream is pending, loading, successfully loaded, or has errored. This means that every component has to implement 4 different code branches per content stream to account for every possible state. On top of that, every additional content stream contributes multiplicatively towards the number of branches that you need to maintain in the code.

Every possible branch leads to additional logic to account for that branch in the code, which in turn increases the complexity of the React code. As the complexity rises, it becomes more and more difficult to keep the code readable. This will lead to worse maintainability, which can be a serious risk long-term for any React codebase. Therefore, it’s very important to make sure that the code for handling React content states stays readable, starting at the most fundamental level.

In this article, I will go over the two most common ways to handle content states in your React components. We will discuss the advantages and drawbacks in terms of readability, and the use cases for every structure. This information will provide you with a solid foundation on how to implement content states in your React components in a readable manner. After this article, you will be able to apply these structures, identify when your code declines in readability, and keep more complex constructions readable by building on top of this knowledge.

This article is part of Uncommon React, a newsletter focused on helping you become a better React developer by focusing on the less commonly discussed topics, like testing, readability, and more.

Handle States In The Render

The most common approach you will encounter is handling the content states directly in the render through conditionals. What you do is check for a specific content state and based on it conditionally render code that reflects the UI for that content state. Generally, it would look as follows:

export const ComponentWithContent = (props) => {
    // Code...
  return (
      <div className="container">
        {contentState === "pending" && <span>Pending...</span>}
        {contentState === "loading" && <span>Loading...</span>}
        {contentState === "error" && <span>An error has occurred...</span>}
        {contentState === "success" && <div>{/* ... */}</div>}
      </div>
  );
}

Here we have a component with a variable that captures the state of a content stream. The stream could be coming from anywhere: props, state, a hook, or external code. In the context of this article, this is all considered the same and does not affect anything that will be discussed. The most important aspect is that there is a variable that captures the content state.

In the render, we check for the different possible content states and render UI based on it. In this example, we make use of the AND operator. But all the same would apply even if the conditionals were implemented differently. For example, using ternary operators or composite components that handle the state.

export const ComponentWithContent = (props) => {
    // Code...
  return (
      <div>
        <State value={contentState}>
          <State.Pending>
            <span>Pending...</span>
          </State.Pending>
          <State.Loading>
            <span>Loading...</span>
          </State.Loading>
          <State.Error>
            <span>An error has occurred...</span>
          </State.Error>
          <State.Success>
            <div>{/* ... */}</div>
          </State.Success>
        </State>
      </div>
  );
}

The biggest advantage of handling all the cases of the content stream in the render is that everything is exactly in one place. When reviewing, going through the code, or refactoring it, you only have to look at one place. You will immediately get an overview of the entire structure and see how the content states are handled.

Another advantage is that the similarities and differences are clear. In particular, this structure focuses on similarities while highlighting minor differences. Based on where the conditionals for the content states are placed, it’s relatively easy to determine what code is shared and what code is specific for a certain state. Not only does this improve the readability, but also the future maintainability as this is crucial information to have when refactoring such a component in the future without prior context.

Because of the way this structure focuses on similarities and highlights differences, it works great in scenarios where the different content states have either similar DOM structures or only affect similar areas of the DOM. In those cases, the different branches are grouped at the location that they target in the render function. If you are reading through React code from top to bottom, this will feel very natural as the last section is always the render and greatly improve readability.

Take the example at the start of this section. All of the branches are nested inside the container element. While reading, refactoring or reviewing this code, two things are immediately clear. First is that the UI for all the content states is the same up to and including the container element. The second is that the content only affects the UI in this particular area, the children of the container element.

In the context of this trimmed down example, these nuggets of information are not too significant. But in real-world scenarios, DOM structures are usually significantly larger. Navigating your way through them is not a trivial task, let alone being able to identify similarities and differences, which is important for refactoring and maintainability. In those cases, every bit of information adds up and handling all content states in the render is one way to improve readability.

While we have discussed the advantages and use cases, there are also scenarios where this approach will actually hurt the readability more than it does good. As mentioned, this approach works great if the different content states have similar DOM structures or only affect similar areas of the DOM.

If these do not apply to the component, then implementing the content states using this approach can become quite a mess. If a lot of different areas of the DOM are affected by different content states, this approach will result in a lot of distributed conditionals inside your render. While at a low number this isn’t too bad, the readability of your React code will greatly decrease as the number of conditionals increase because they are relatively verbose.

This is even worse if the content states have varying DOM structures. Trying to create one large structure that will accommodate all of them rarely does anything good for the readability of the code. It will split up your code into even larger conditional blocks and distribute them over different locations and even nesting levels. This will result in an extremely convoluted and hard-to-follow DOM structure, which will only hurt the code readability.

Summary

✅ Everything is structured in one place.
✅ Focuses on similarities and highlights differences.
✅ Works great if content states have very similar DOM structures or affect the same area of the DOM.
⛔ Will result in a lot of distributed conditionals in the render if content states have different DOM structures.
⛔ Code can become a big mess where large blocks are separated conditionally and at different nesting levels.

Handle States Through Early Returns

Another approach to handle content states is through early returns. This approach puts the conditionals out of render and moves them up in the component. When the condition is met, the component does an early return with the appropriate code. This continues until all the content branches are handled and all the options are exhausted. Generally, it would look as follows:

export const ComponentWithContent = (props) => {
    // Code...

  if (contentState === "pending") {
    return (
      <SomePendingComponent />
    );
  }

  if (contentState === "loading") {
    return (
      <LoadingSpinner />
    );
  }

  if (contentState === "error") {
    return (
      <ErrorMessage>An error has occurred...</ErrorMessage>
    );
  }

  return <div>{/* ... */}</div>;
};

In the example, the component first checks whether the content stream is still pending. If so, it will do an early return with a component that is specific to the pending state. If not, we will continue and immediately check for the next possible state. The same goes for the loading state and then the error state. Lastly, we are sure that all the other options were already exhausted so the last case to handle is the success state, which we can do through a regular return.

The biggest advantage of this approach is that this structure requires the least effort of keeping track of the data flows when reading through the component code top to bottom. The code is always only tackling one state at a time. This means that when you read it, you only have to remember which state you are in, which is indicated by the conditionals. Then, when you enter the block statement, you know that everything inside of the block is only related to that particular content state. This decreases the burden on the reader to constantly have to keep a mental modal of the UI, the similarities between states, and the differences. Rather, they can focus on a single state at a time, like reading chapters of a book, and move on to the next state when they are done.

In line with this is how people most commonly prefer to go through the different content states. Based on what I personally do and saw from other people, we most of the time prefer to first handle the loading states, then the error one, and then leave the success state for last. This approach fits exactly in that preference and thus match the structure of the code the most with the expectations of readers. This will make the code more natural to follow and to read, thus benefitting the readability.

This approach works really great if the different content states lead to totally different DOM structures. If similarities are small, then it’s becomes very difficult to both maintain the readability and keep the code together while still accounting for all the differences because there are a lot. So instead, the content cases are separated from each other and handled on their own. This puts most of the emphasis on the differences. The more different the DOM structures for the content states are, the more this approach enhances the readability of the code.

The best-case scenario for this approach is that every content state has a totally different DOM structure as that maximizes the readability of this approach. But that is not always possible or applicable in real-world scenarios. Likely, there will still be some similarities in structure between content states, which is also the main drawback to this approach.

In general, handling content states through early returns does really well to accommodate for differences, but is very bad at accounting for similarities. Because of the way it tackles content states one entirely at a time, code will have to be duplicated if similarities occur. The more code is shared between the content states, the more code duplication it introduces to the React component.

Another drawback of this approach is that the code and logic for handling the content stream are distributed vertically all over the component. It’s impossible to get a quick overview of how all the different content states are handled. Instead, if the readers need a complete picture e.g. refactoring, they are required to go through all of it top to bottom and compare them case by case. This can take quite some time and effort.

Another drawback is the distance that is created between the code for handling a certain case and the utility code related to it. The usual structure of React components is that hooks reside at the top. Not only is this a convention, but also a requirement as they can’t be conditionally called. In this approach, we’re actively creating distance between that code and code for states that are handled later in the component. The later a state is handled and the larger the code for handling the other states are, the more distance is created relative to relevant (state) variables, callbacks, or hooks. In certain scenarios, the distance can become so big that it actively obstructs how efficiently the reader can go through the code and understand it, thus diminishing the readability.

Summary

✅ Tackling one content state at a time.
✅ Readers don’t have to keep a full mental modal of the similarities and differences, but can just focus on the current state that is handled.
✅ Leaves the success case for last, which is the reading style a lot of developers prefer.
✅ Works great if content states have very different DOM structures.
⛔ Doesn’t handle code similarities well, which can quickly lead to a lot of code duplication.
⛔ Impossible to get a quick overview of the content states logic.
⛔ Vertical distance between content state logic and their utility code (variables, callbacks, and hooks) can obstruct the readability if it becomes too big.

Final Thoughts

Content streams are an important part of any React project. They make React applications live up and interactive for the users. But from the development perspective, your components become complex very quickly as the number of content streams increases. This leads to a multiplicative increase in the number of content states that the components need to handle. Long term, making sure that this code is readable has a serious impact on maintainability.

In this article, we discussed two fundamental approaches to handling content states in your React components. Either handling them in the render, using conditionals or composite components or handling them through early returns. Both have their advantages, drawbacks, and use cases in terms of readability. This information provides you with a solid foundation on how to implement content states in your React components in a readable manner. You will be able to apply these structures, identify when your code declines in readability, and keep more complex constructions readable by building on top of this knowledge.

3 Levels of Mocking a React Hook: Control and Effort against Representability

Chak Shun Yu — Tue, 06 Jul 2021 20:26:11 +0000

Hooks are one of the most important aspects of any React project. Whether big or small, whether it is custom or not, every hook is responsible for a piece of logic and interactivity of the frontend application. Because of this, it is all the more important that they are dealt with correctly in frontend tests. But there are different ways to mock a React hook, all of which have different advantages and drawbacks.

Over the years, I have encountered this issue numerous times. A lot of the questions that come with it are: how should I deal with a React hook in my frontend test? Should I mock it or not? Is it even possible to mock it? How should I mock it? How much effort does mocking the hook require? Should I mock the entire hook or should I mock only certain parts of the hook? How does it impact the representability of my tests?

The interesting thing is that despite this set of questions remaining the same every time and every scenario feeling similar to the previous one, the answers to this set of questions were always slightly different. This meant that the solution would also be slightly different every time. In all of them, the considerations that made up these slight differences were also always regarding the same two factors in my experience.

On one axis, there is the control related to mocking the React hook. This describes the amount of control that the developer has over mocking the hook. The more control the developer has over the mocked hook, the more they can influence its behaviour and outcome in tests. Obviously, it is preferred to have as much control as possible from a development perspective, as that provides the most possibilities. But the amount of control goes hand-in-hand with the amount of effort that is required by the developer to deal with the hook. Having more control over the hook in tests means that the developer needs to consider more options, have a better understanding of the use cases, and do more to handle it properly.

On the other axis, there is the representability of the resulting test. This describes how realistic of a reflection our tests are of real end-user experience. Depending on how a React hook is mocked in the testing environment, different approaches can affect the representability of our tests in various ways. The higher the representability of our tests, the more it means that the tests are a realistic reflection of end-user experience, the more we can trust the test results to tell us whether a feature is broken or not, and thus the more value the tests provide.

Based on my experience, these axes were always opposite to each other. This meant that a solution that provided the developer with a lot of control and effort over mocking the hook would result in a test with relatively low representability. Vice versa, making sure that a test had very high representability of the actual user experience would require an approach that left me with little control and effort.

As ideally, we would maximise both axes, every time the consideration would boil down to balancing these two factors. Between the control and effort of mocking the hook and representability of the resulting test, which aspect are we willing to sacrifice for the other and how much?

In this article, I will go over the different ends of the spectrum and describe the different considerations that come with it. The purpose is to provide you with a clear understanding of this balancing act and the considerations that come with it. Using this, you can apply these considerations yourself the next time you are thinking about what the best approach is to mock a React hook and enhance the quality of your tests.

All of this is also framework agnostic. So whether you are working with Jest, Enzyme, Mocha, Jasmine, React Testing Library, another testing library, or any combination of the previous, you will still be able to apply what you will learn from this article to create more quality solutions to mocking hooks in React tests.

Mock The Entire hook

The most drastic measure to deal with React hooks in tests is to mock them away entirely. From a development perspective, this is the simplest approach, requires the least considerations and effort, and provides the most control. There are several ways to technically implement this, but the most straightforward approach would be something along the lines of:

// ComponentWithCustomHook.test.jsx
jest.mock("./hooks", () => ({
    useCustomHook: () => { customString: "some-string", customCallback: jest.fn() },
}))

What we are doing is mocking the entire hooks module and overwriting it with our implementation in the test environment. In this case, we replace the useCustomHook export with an anonymous function that returns some dummy values. Whenever the custom hook is now called inside our tests, it will always return the dummy values that we provided.

There are several ways to diverge from this implementation based on your library and needs, like saving mocks for verifications, mocking a third-party library, and so on. But the concept behind all of them remains the same, namely that we want to mock the entire hook and control its behaviour entirely in our tests.

This approach provides the most control from the developer’s perspective. All you have to worry about is what the hook should return to your components in your tests. You do not have to worry about how the custom hooks work internally — no matter how complex the inner state, whether any network requests are performed, what dependencies it has internally, or whatever is done inside the hook, you do not have to care about that in any way as that will be mocked away. You can configure exactly how the hook influences different test scenarios by tweaking the mock. If you want to verify happy paths, then you can make the mock return exactly what you expect from the original hook in those scenarios. And the same applies to verifying unhappy paths. The control is entirely yours.

The biggest sacrifice with this approach is made in terms of the representability of the resulting tests. From a user perspective, this is the least representative of how users would interact with your application. While you gain simplicity, time, and control over the mock’s behaviour, you are actively diminishing the amount of actual code that your tests go through. Instead, strong assumptions are made regarding the input, the logic, and the expected output of the hook. In turn, the credibility of your tests is dependent on how valid these assumptions are.

But no matter how strong these assumptions are, mocking a hook still means you are getting rid of an essential part of your front end. Thus, when opting for this approach it is very important to consider whether you really need all this much control and the gained time and effort. Because of it, you are sacrificing a lot of the representability of your tests. In certain scenarios where the hook does not significantly affect the experience of the users, this can be a reasonable decision to make. But in a lot of other cases, this rarely applies.

Only Mock The Internals Of The hook

Another option to deal with a React hook in your frontend tests is to not mock the hook itself but to only mock certain internals of the hook. Prime candidates for this are interactions with external resources that determine the internal behaviour of the hook, like API calls. You could also think of expensive or complex calculations or the usage of code from third-party libraries.

Mocking the internals of React hooks will provide you with more fine-grained control over the result of those parts of code, but still, leave your part of the React hook untouched. Control and effort-wise, this is like a middle ground as this approach sacrifices a bit in both aspects compared to mocking the entire hook

Rather than controlling the entire hook, you now only control a part of it. Effort wise, you now have to dive into the internals of the hook and figure out how it works before you can properly mock them. In certain cases, this can require quite some additional time and effort. The most common case would be if you are dealing with hooks that were not written by you but rather by other parties, like third party libraries or other teams.

While you lose some points on the axis of control and effort, you gain some of it back on the representability one. Compared to mocking the entire hook, you are now only cutting off your React hook from reality at certain parts of the code. This means that you leave the other code in the hook untouched. Oftentimes, those are responsible for handling how your hook and components behave based on the results of those internals. Since you are not mocking those away anymore, your tests become a more realistic representation of how users would also perceive it during usage.

This approach is the biggest grey area on the spectrum between the two axes. A lot of the scenarios that you will come across will fall into this area. This area is also where most trade-offs are considered between the two axes and most minor solutions originate. It is a constant optimization process between how much representability can be sacrificed for control and effort, and vice versa how much control is worth the effort and necessary to justify the loss of representability.

Leave The Hook Untouched

On the other side of the spectrum compared to mocking the entire hook, there is also the option to not mock the hook at all. From a representability perspective, leaving the hook entirely untouched is the most preferred way of dealing with it. It is most similar to what end-users will experience while using your application, which is the best-case scenario for a testing environment. Applying this approach will maximise the representability of your tests.

However, these benefits do not come for free. While the representability greatly benefits from this approach, you will have to sacrifice a lot of control that you have of the hook in your tests. In fact, all of it as you are not touching the hook at all and are relying on the production behaviour. But this is basically what we want right, a testing environment that exactly matches our production environment so the rest results accurately match whether the features are broken for our end-users?

Well, not quite.

In certain cases, this approach is an infeasible or impossible way of dealing with React hooks. Performing network requests to an external API is a common occurrence that falls into this category. Not even considering realistic factors like API request limits, allowing your code to perform network requests in tests can introduce non-deterministic behaviour. This can in turn lead to the same tests having different results between test runs based on external factors that are out of your control, also known as being flaky tests. This is exactly not what you want from your tests.

In an ideal situation, our test environment would be an exact reflection of our production environment. Then, our tests would also be an exact reflection of how our application is working for our end-users, assuming tests are implemented properly. This approach tries to create such a situation, but unfortunately, in practice, it is not a realistic one. Depending on a lot of different factors, our test environment can't be an exact reflection of our production environment without additional effort that is outside the scope of this article.

On the rare occasions that it is possible to leave a hook entirely untouched without any impact on the effort and the representability of your test, it is recommended to do so due to the importance of representability. But in the majority of the cases, it is important to consider whether sacrificing so much control is worth the gained representability and also the effort that potentially comes with it. Instead, sacrificing a small and reasonable amount of representability could result in a lot of control and saved effort, which is a more realistic decision to make in certain scenarios.

Final Thoughts

This article looked at three different approaches to mocking a React hook along the spectrum of the two axes that they consider. The first one being control that we have and the effort that we have to put in as developers, while in the opposite direction there is the representability of our tests compared to end-user scenarios. All described approaches are balancing between these two axes in different proportions. Mocking the entire React hook and leaving the hook untouched are on the outer ends of the spectrum for respectively control and effort, and representability. For both ends, there are scenarios in which they have their use cases, but those are less common.

In the middle of the spectrum, there is the approach of only mocking the internals and certain parts of the hook. This is an enormous grey area where a lot of small considerations can be made according to the different scenarios, which is the reason why similar cases can lead to different solutions. Based on the details, there are a lot of different ways in which mocking a React hook can be done. In the end, the most important thing to remember is that it is a balancing act on the spectrum between control and effort against representability: how much are you willing to give up and how much are you willing to reasonably sacrifice?

If you liked this story, consider following me on Twitter to stay up to date with my work or checking out some of my other work here:

How To Mock Only One Function From A Module In Jest

Chak Shun Yu ・ Apr 20 ・ 5 min read

#beginners #testing #programming #javascript

Why I'll definitely use mapDispatchToProps in Redux

Chak Shun Yu ・ Jan 5 '20 ・ 4 min read

#webdev #testing #react #redux

Why Pair Programming Should Be Part of Every Team Dynamic

Chak Shun Yu ・ Jun 4 ・ 8 min read

#programming #productivity #career #beginners

Why Pair Programming Should Be Part of Every Team Dynamic

Chak Shun Yu — Fri, 04 Jun 2021 21:23:48 +0000

Only when I started a new job earlier this year did I discover the concept of pair programming in an engineering team and since then I have become quite fond of it. I really like the interactions that it creates between team members and working together on a certain task. Having experienced a team where pair programming was not a thing and a team where it was, I can definitely say that there are a lot of benefits to pair programming and it can greatly contribute towards a team. In this article, I will go over what pair programming can do for your team and why your team should also adopt it.

Learning from each other

No two developers are alike. Every developer has their own way plan of approaching a task, works differently, does things in another way, has different nuggets of information, and so on. This means that there is always something to learn or pick up from another developer, also regardless of any difference in years of experience. It could be a simple coding trick, an optimization in the working process, a specific shortcut, a way of thinking, and a whole lot more.

Pair programming creates moments that allow knowledge sharing to happen. By putting these developers together, it makes them observe each other’s way of thinking and style of working. Doing so will provide us with the chance to learn something from one another that can make us better, more efficient, or more clever in what we normally do. In turn, this will elevate the skills of every developer as well as the quality of the team as a unit.

Two minds are better than one

In almost all scenarios will two developers come up with better ideas and solutions than an individual developer. If every member of an engineering team works separately, then every time everyone will create a proposal (Pull or Merge Request) for their work and receive input from other team members during the review process. But if you do pair programming inside a team, then the approach and feedback from one other team member are already mixed into yours. The result is a proposal that is already more refined and basically a mix of two developers’ approaches rather than just one.

This will first of all will make everything after the proposal, like the review process, more smoothly and create less back and forth between the proposer and the reviewer. On top of that, it will make developers more aware of their own way of working during the coding process. Since they will be exposed to the approaches of other team members, they will be made aware of certain parts that they under normal circumstances might not have paid too much attention to. As a result, pair programming will make team members polish each other’s way of working and elevate the quality of the work of both the individuals and team as a whole.

Levels out knowledge gaps

One of the biggest concerns for an engineering team is its truck factor. The truck factor of a team is the minimum number of members that have to suddenly disappear before projects have to stall because there’s too big of a lack of knowledge to continue with the project.

In smaller teams, it’s not too weird to have individual developers responsible for projects. Especially in those scenarios, without any intervention, the truck factor can become dangerously low and have significant business risks long term.

The main cause of a team’s truck factor is the presence of knowledge gaps between members. The more separated members work from one another, the lower the truck factor becomes. Pair programming helps a team in increasing their truck factor by putting more developers onto a task and increasing the horizontal sharing of crucial project-related knowledge. These two factors together will in turn level out knowledge gaps in a team and increase the truck factor to a safe level.

Pair programming is great for newcomers

Onboarding newcomers to an engineering team is by far not a trivial task. It’s a difficult process for all the parties involved, both the team as the newcomer. For the newcomer, there is so much to learn, to absorb, to prepare, to set up, and to find out, like how the team works, how the team approaches certain tasks, and so on. But for every aspect that the newcomer has to receive, the team has an equal responsibility of providing the newcomer with the appropriate resources in a proper way.

The most optimal solution would be to document literally everything about a team so that the newcomer can reach for that document at any moment and place. But in reality, this is an infeasible thing to accomplish. Creating such a document requires a tremendous amount of effort and time. Even if such a document is present, there’s a high chance that it’s incomplete or outdated. Keeping such a document up to date would also introduce another tremendous amount of required maintenance to the table.

So instead, most companies or teams will have created a generic onboarding that every newcomer will have to go through. But the issue is that every developer has a different way and pace at which they absorb certain information most efficiently. It’s impossible for the teams though to be considerate of every edge case beforehand. The ratio of the required effort and time to creating and maintaining such a one-size-fits-all solution against the frequency it will be used and the impact it will have is extremely disproportional.

A great addition to make it more personalized and better assist newcomers that I have experienced is to include pair programming sessions in the onboarding. Regardless of which role the newcomer has during such sessions, they will have the chance to process new information practically and make it their own.

If the newcomer is the driver, then they don’t have to worry about the overall process that they are not aware of yet. An existing team member will be the navigator and in this setup have the guiding role. They will make the general process decisions for the newcomer, walk them through why and how, adjust their course if necessary. So as a driver, the newcomer can focus on doing what they know (writing code), but also immediately get the chance to absorb the new information through hands-on experience.

The other way around, when the newcomer is the navigator, can also be very useful. Contrary to being a driver, the newcomer will have a more passive role as a navigator in which they will focus on observing the existing team member while performing their work. While the following applies to both roles, it’s more prominent in this scenario. Namely that the newcomer as the role of navigator has more influence over the pace of the pair programming sessions. By asking questions and pointing out topics that they couldn’t quite catch the first time, they gain a more active role in controlling the pace of the sessions. So as a navigator, the newcomer can be observant and control the speed at which they absorb information to what is most effective for them.

Keeping one another in check

There’s a high chance that every developer has experienced the scenario before where during a task they encountered a small issue that sparked their interest. They wanted to investigate it a little bit but ended up digging themselves into a rabbit hole on the internet to figure everything out about it. Truth is that working on your own can more easily cause this, which can lead to spending a significant amount of time on something that might not be worth it. This isn’t necessarily a bad thing and being curious is generally good as a developer, but it is an example of putting an incorrect amount of focus and priority on something.

Pair programming with someone can help avoid this issue by keeping each other in check. If one party notices that the other is getting sidetracked or too much attention is spent on a topic that seems trivial to them, then they can mention it. The other way is also true, namely if one party notices that the other party is treating a certain issue as trivial while they believe that it’s quite complicated.

When there are divided opinions in a pair programming sessions, they will have to be discussed because otherwise, both parties will have a different interpretation of the pace of the session. One will think it too fast-paced, while the other thinks it can go faster. This is unpleasant for everyone involved. This will lead to communication and both parties will have to discuss what the correct pace is, thus discussing whether the current issue at hand is worth the amount of time and effort that they are now putting into it. This way team members will keep each other in check and also result in issues being more properly analyzed and estimated.

Improves connections between team members

A more social reason to stimulate the activity of pair programming is that it improves the connection between team members. As mentioned in the other sections, pair programming is really something that happens between two developers. Communication is an essential part of this process. To make the most of pair programming sessions, all parties must be trying their best to get the most out of them for the sake of themselves. If this doesn’t happen, they should therefore communicate it to the other party. This can be done through asking questions, voicing their opinion on the pace of the session, mentioning an overlooked issue, not agreeing with a certain approach and a whole lot of other ways.

To continue smoothly with the sessions, the other party is required to address the feedback and come to an agreement on how to approach it. This could for example be done by means of coming to a conclusion through a two-sided discussion or agreeing on a middle ground solution that satisfies both parties. The only way this can happen is through proper communication. In these moments team members will have to learn how to interact and discuss with each other. Thus in the long term, pair programming will improve the communication and connections between team members.

In this article, I went over what the concept of pair programming can do for a team and provided reasons why I think every team should adopt it based on my experience. Knowledge sharing between team members is one of the greatest benefits of applying this concept, as they will be able to learn from each other and come up with more refined solutions together. It’s also a really great addition to personalizing the onboarding of newcomers more suitably while existing team members can use it to keep one another in check during the coding process. For the team as a whole, it means that long term knowledge gaps will become more levelled out, which in turn helps out with the team’s truck factor, and the connections inside the team will be improved.

If you liked this post, I recommend checking out some of my other work over on my personal blog or following me on Twitter to stay up to date with my work. Some related posts are:

5 Ways to Make Pair Programming Sessions More Effective

DEV Community: Chak Shun Yu

How To Create More Intuitive Styling Using CSS border-box Box Model

The Default content-box Box Model

The border-box Box Model

Multiline Text Truncation With CSS line-clamp

Workaround Methods

CSS’s line-clamp

Summary

A Fundamental Guide To React Suspense

What is Suspense?

Why do we need Suspense?

Fetch-on-render

Fetch-then-render

How does Suspense solve the data fetching issues?

What are the benefits of Suspense?

Final Thoughts

An Introductory Guide To Concurrent Rendering

Why do we need concurrent rendering?

What is concurrent rendering?

What’s Next

5 Reasons React Is Still Worth It To Pick Up In 2022

Still Extremely Popular

High Job Demand

Large Active Community

Strong Ecosystem

Still More To Come

Final Thoughts

Top React Development Trends for 2022

Remix

Server-Side Rendering

Concurrent Rendering

Behaviour Testing

Honourable Mentions

Final Thoughts

Do You Need To Master JavaScript Before Learning React?

Final Thoughts

My Simple Checklist For Well Tested React Components

User Interactions

Product Manager Requirements

Internal Components And Utility Functions

Backwards Compatibility Features

Regressions

Final Thoughts

Are Your Pull Requests Hard To Review? 5 Tips To Make Them Easier

Leaving Out Contextual Information

Including Unrelated Changes

Letting The Reviewer Figure Out Everything Themselves

Have Meaningless Version Control History

Rewriting Version Control History On Every Change

Final Thoughts

How To Write Readable React Content States

Handle States In The Render

Summary

Handle States Through Early Returns

Summary

Final Thoughts

3 Levels of Mocking a React Hook: Control and Effort against Representability

Mock The Entire hook

Only Mock The Internals Of The hook

Leave The Hook Untouched

Final Thoughts

How To Mock Only One Function From A Module In Jest

Chak Shun Yu ・ Apr 20 ・ 5 min read

Why I'll definitely use mapDispatchToProps in Redux

Chak Shun Yu ・ Jan 5 '20 ・ 4 min read

Why Pair Programming Should Be Part of Every Team Dynamic

Chak Shun Yu ・ Jun 4 ・ 8 min read

Why Pair Programming Should Be Part of Every Team Dynamic

Learning from each other

Two minds are better than one

Levels out knowledge gaps

Pair programming is great for newcomers

Keeping one another in check

Improves connections between team members

The Default `content-box` Box Model

The `border-box` Box Model