Forem: Alex

Printing Perfection, A Developer’s Journey with React-to-Print

Alex — Mon, 15 Jan 2024 21:16:40 +0000

Image by OpenClipart-Vectors from Pixabay

As a requisite for a commercial application, sometimes it's needed to implement a printing solution that is not the browser's default.

Why the browser print API is limited

While we are accustomed to using CTRL/CMD + P to print a page, we know as a fact that often the layout that is presented is not ideal. Especially if we are using other UI libraries that are injecting their components with their hidden styles.
There can be elements out of order, fonts changing size, and so on.

One solution that many of us have tried is just to save the pages as PDFs and print them instead. While this method sometimes worked, we wanted to provide an effective solution to our clients so that all the important data would be visible, clear, and organized on the layout of the printed page.

The search

I checked various libraries but eventually, my eye fell on the one called "react-to-print".

I'll be writing shortly about why I chose it, so it could maybe helpful to other developers who are starting their journey and would like to know how a new library is chosen for a work project. Compared to other libraries, it was a solution that, first of all, was not designed to create a PDF and then print it, but to use the native browser print API and it is just built on top of that.

Secondly, the number of weekly downloads (400.000) and how many people were already using it from Github (30.5k) helped me move forward in this direction. The library is pretty weightless, just 51kB. It is just one Javascript file. The rest are Typescript definitions and other add-ons.

Why wouldn't we do it ourselves, then?

First of all, no need to reinvent the wheel and lose time when you have a timeline of features to follow for the clients.

Secondly, the library has been so far maintained by 35 people and has multiple versions published in the year. Which is much more of what we could do, even sparing hours every week on it. Lastly, it is Typescript first, so it's easier to use and safer to use it correctly.

POC

Before finishing the analysis, I did a proof of concept (POC). I opened a new branch and tried to implement it in a very rough way, just to see that nothing was breaking and it was working on the base concept.

It was a little hard as the documentation is not so straightforward, especially as it highlights the usage of React's old class components, and there are just two examples with functional components.

However, thanks to some other kind soul who posted some solution on its usage (which was different than what the documentation suggested) I could make it work, and show a good printing layout with a small print button.

Work in progress

Our business analysts, then, prepared the specifications and assigned them to new ticket stories. After having been refining them, on the next Sprint, I took charge of them, as I already knew part of the job.

Of course, it didn't come as easy as the POC. There were multiple requirements in the specs and lots of nuances that had to be checked. Also, lots of bugs in styling the printing layout. First of all, I had to add the CSS query for hiding elements on print. Normally it would be a new class like this:

@media print {
  .print {
    display: none;
  }
}

Luckily we are using Tailwind, and the utility for this is simply to add: print:hidden to the components or divs we want.

The first issue I came across was the usage of components of the library. As the POC worked fine, I started implementing it with the component. After struggling with it for some time, I realized that because I needed not only the component where was, but I also needed the reference in a child component, this couldn't be used.

I figured then that I had to use the custom hook provided by the library, as the hook result could be passed as a prop and used elsewhere. Also, the hook provided a way to implement various custom options more easily. The main way on how to do it is this:

const handlePrint = useReactToPrint({
  content: () => componentToPrintRef.current,
})

HandlePrint is a function, so it can be called anywhere you want that action. It can be passed to other components as prop to call the print action from somewhere else. The component that will be printed is inside the componentToPrintRef reference. So you can wrap it in a very simple way:

<div ref={componentToPrintRef}>
  <Components />
</div>

Then, you can add wherever you wish a button or link to call handlePrint. That's the basics, and on a simple page, it works nicely out of the box. However, I had to add a few things:

Handle keys. We wanted the print happening not only with the button(s) but also on CTRL/CMD + P keys, as it happens with the browser.
Hide not only CSS elements but also checkboxes and other elements depending on the state.

To make the first feature happen, I added the event listeners. A function taking the event as a parameter and, if the keys combination was of the aforementioned, calls handlePrint(). Then, a useEffect would be this simple way:

useEffect(() => {
  document.addEventListener('keydown', handleKeyDown)
  return () => {
    document.removeEventListener('keydown', handleKeyDown)
  }
}, [handleKeyDown])

So far, it's something pretty regular. However, when it came to the second point, things got a little more complex. The most immediate solution was to create a state for printing using useState.

Then, somehow, setting it inside the print hook. ReactToPrint offers some methods to handle that inside the customHook. One is onBeforeGetContent to create a custom layout set before taking the actual CSS and HTML elements. The easier way was a function, as it is a function, to set the isPrinting boolean to true. Then pass isPrinting to the various components to hide the needed elements and not show them on the print layout.

However, that wasn't working normally. Sometimes the components were hidden, sometimes not. It probably meant that the state was not synced or waited for. After some research, and thanks to the people who wrote examples also in the library GitHub Issues section, I saw that onBeforeGetContent was expecting a Promise. The issue above then made sense. The change of state was not waited as there was no callback to let it wait.

Adding a new Promise() with parameters of resolve and value, I could then call setIsPrinting to true, and then resolve the value. On exit of the layout, instead, I used the method onAfterPrint, which was simple enough to just set setIsPrinting to false to get back the hidden components.

Now, another issue came out. Whenever I was clicking on Cancel or Print on the browser print layout, the dialog was closing. But if I tried to print again, the layout was all scrambled, making it as if the library was not there at all and it was using the default from the browser. After some thinking, I realized that it wouldn't happen if I interacted with the page elements between two prints.

So it must have been that, for some reason, without clicking on the page the library methods were temporarily removed. The solution was to focus on the page after exiting the print layout. As the element of reference is an HTML element, we can use that in the onAfterPrint method: componentToPrintRef?.current?.focus()
However, it was not focusing!

Why? It's because the focusable elements are only form elements, like input, select, and button. Or link tags with an href element. But the main point is the tabIndex attribute.
It is indeed that which is causing the element to be focused. So I added it to the print reference div: <div ref={componentToPrintRef} tabIndex={-1}>

Why -1 instead of 0? 0 makes the element focusable and adds it to the natural tab order of the page. But the page has already sections and headers and items that are possible to navigate with the keyboard, so it would create issues. -1, instead, makes the element focusable, but it removes the element from the natural tab order.

Conclusion

In the ever-evolving world of web development, finding effective solutions to seemingly simple tasks, like printing, can often be a challenge.

I have tried here to go through the process of implementing a robust printing solution using the “react-to-print” library. It focuses on utilizing the native browser print API, which has proven to be an effective solution, despite the hurdles along the way.

This journey underscores the importance of continuous learning, problem-solving, and the power of community in the field of web development.

How to Handle Scroll Events in React

Alex — Wed, 25 Oct 2023 06:08:00 +0000

Photo by Taylor Flowe on Unsplash

In this blog post, we’ll explore how to handle scroll events in a React application. We’ll focus on an issue developers could face: synchronizing state with the scroll position.

The Problem

Imagine you’re building a complex UI with multiple sections, and you want to highlight the navigation link of the section currently visible in the viewport. Not only that, you would like to be able to click on the sections and scroll to the corresponding one. You might think of using a scroll event listener that checks the scroll position and updates the state accordingly.

However, you may encounter an issue where your state updates continuously, causing unnecessary re-renders and performance issues.
Unfortunately, the only browser API for it, called scrollend event, is not compatible and implemented in Safari, nor in iOS, Samsung or Opera browsers, so it can't be really used on a large scale.

The Solution: Debouncing

To solve this problem, we can use a technique called debouncing. Debouncing is a programming practice used to ensure that time-consuming tasks do not fire so often. This can be particularly useful for rate limiting execution of handlers on events that will trigger requests.

Here’s how you could implement a debounce function in TypeScript, in a very abstract method:

function debounce(func: (...args: any[]) => void, wait: number) {
  let timeout: NodeJS.Timeout;
  return function executedFunction(...args: any[]) {
    const later = () => {
      clearTimeout(timeout);
      func(...args);
    };
    clearTimeout(timeout);
    timeout = setTimeout(later, wait);
  };
};

This debounce function takes two arguments: func, the function you want to debounce, and wait, the number of milliseconds to delay before executing the function.

Checking if an Element is in the Viewport

To determine which section is currently visible in the viewport, we can use a helper function:

function isElementInViewport(el: HTMLElement) {
  const rect = el.getBoundingClientRect()
  return (
    rect.top >= 0 &&
    rect.left >= 0 &&
    rect.bottom <= (window.innerHeight || document.documentElement.clientHeight) &&
    rect.right <= (window.innerWidth || document.documentElement.clientWidth)
  )
}

This function takes a DOM element as an argument and uses the getBoundingClientRect method to get its position relative to the viewport. It then checks if the entire element (from top to bottom and left to right) is within the viewport dimensions. If it is, the function returns true; otherwise, it returns false.

We can use this function in our scroll event listener to check if each section is in the viewport and update our selected state accordingly.

By combining these techniques, we can create a dynamic navigation system that responds to both user interactions and scroll events, providing a smooth and intuitive user experience.

Applying Debouncing to Scroll Event Listener

We can apply our debounce function to the scroll event listener in our React component:

useEffect(() => {
  const handleScroll = debounce(() => {
    if (!isScrolling) {
      const sections = document.querySelectorAll('.section')
      sections.forEach(section => {
        if (isElementInViewport(section as HTMLElement)) {
          setSelected(() => section.id)
        }
      })
    }
  }, 500); // Adjust this value as needed

  window.addEventListener('scroll', handleScroll);

  return () => {
    window.removeEventListener('scroll', handleScroll);
  };
}, [isScrolling]);

In this code snippet, we’re adding a scroll event listener that fires our debounced function. This function checks if we’re currently scrolling and if not, it checks each section (through a class name to be applied) to see if it’s in the viewport. If it is, it sets the selected state to the ID of that section.

By using debouncing, we ensure that our event handler doesn’t fire too often and cause performance issues. Instead, it waits until a certain amount of time has passed without the event being fired before executing.

Handling Click Events

In our React component, we may want to handle click events that trigger scrolling to a specific section. Here’s how we can do it:

const handleOnClick = async (value: any) => {
  setIsScrolling(true)

  const element = document.getElementById(value)

  if (element) {
    element.scrollIntoView({behavior: 'smooth'})

    setTimeout(() => {
      setIsScrolling(false)
      setSelected(() => value)
    }, 500)
  }
}

In this function, we’re first setting isScrolling to true. Then, we’re getting the DOM element with the ID equal to the clicked value. If such an element exists, we’re using the scrollIntoView method to smoothly scroll to that element.

After a timeout of 500ms (to allow for the scrolling animation to finish), we’re setting isScrolling back to false and updating our selected state to the ID of the clicked section.

Simplifying debouncing

It is even possible to use directly the setTimeout browser API directly, instead of making a function about debouncing. The effect, pardon the pun, will be the same, but the code simpler, if you don't need to reuse it. Otherwise, the debounce function, or even import lodash debounce, will do.

useEffect(() => {
  let timeout: NodeJS.Timeout

  const handleScroll = () => {
    if (timeout) {
      clearTimeout(timeout)
    }

    timeout = setTimeout(() => {
      if (!isScrolling) {
        const sections = document.querySelectorAll('.section')
        sections.forEach(section => {
          if (isElementInViewport(section as HTMLElement)) {
            setSelected(() => section.id)
          }
        })
      }
    }, 100) // set to what is your need; can be lower than the handle on click for it doesn't need too much waiting
  }

  window.addEventListener('scroll', handleScroll);

  return () => {
    window.removeEventListener('scroll', handleScroll);
  };
}, [isScrolling]);

Conclusion

Handling scroll events in React can be tricky due to the asynchronous nature of JavaScript and the way React batches state updates. However, with techniques like debouncing, we can efficiently handle these events and create smooth, responsive user interfaces.
When we have to use two different listeners to take action on our DOM, they can interfere with each other. That's why we need to create some workaround to wait for the changes to happen.

Remember to always remove event listeners when they’re no longer needed to prevent memory leaks and potential performance issues.
If you have other ways of handling scroll events in such cases, please share them!

Testing the styles of DOM elements with React Testing Library

Alex — Thu, 16 Feb 2023 15:49:01 +0000

Photo by Robert Katzki on Unsplash

Sometimes -or often, depending on the case- we need to test some particular style that can change depending on some property.
The way this is implemented depends on the library we use for the styling.

Supposing that we have some text, inside a component, that depending on the prop it's white or black.
In the DOM, it will reflect this way. However, especially as it's not a fixed element, we should test how it behaves on different pages.

The test itself using React Testing Library is very simple because it checks directly the DOM:

  render(<MyComponent>)

  const text = screen.getByText('text in the page')
  expect(text).toBeInTheDocument()
  expect(text).toHaveStyle({ color: '#FFFFF'})

The library converts the colour in hex code against RGB, so if they match, the test will pass; otherwise, it will return the returned RGB colour (i.e. 0,0,0) and the expected one (i.e. 255,255,255). With it, it's very easy to spot the mistake, or why a test is failing.

We can also test directly the prop that we're passing and the consequent change of colour in the component:

  const {rerender} = render(<MyComponent changingProp='white'>)

  expect(screen.getByText('text in the page')).toHaveStyle({ color: '#FFFFF'})

  rerender(<MyComponent changingProp='black'>)

  expect(screen.getByText('text in the page')).toHaveStyle({ color: '#00000'})

You have to notice here that I had to call screen.getByText twice, because that function is returning immediately the DOM element. If I would set it as before in a variable, at the moment of checking 'text' the second time, it would have stored the previous DOM element and not the updated one.

Thank you for reading! Let's connect on Twitter

Removing Default React Imports. For a Cleaner Code

Alex — Tue, 14 Feb 2023 08:44:37 +0000

Photo by Liliana Drew: https://www.pexels.com/photo/a-person-vacuuming-under-a-side-cabinet-9462147/

If you are one of the many people migrating their projects to React 18, maybe you skipped one great feature for your code coming along from the previous version (17): you can remove all default React imports!
To be precise, it was present also in some previous React versions, but it was always somehow hidden from the general public (or maybe just me?).

We were accustomed to the need of importing React in every. single. file.
And maybe you are still doing it after the migration. I did it, indeed, for a while :D

That is because this possibility is in the docs, but on a side note with an enigmatic title: "Introducing the new JSX transform".

In substance, it creates React as a global so it does not need to import it everywhere. How does it work?
It is quite simple. Instead of having:

import React, {useState, useEffect} from 'react'

you can have the normal destructured import without the need to import the whole library:

import {useState, useEffect} from 'react'

or skip it entirely if you don't need any hook.

Also, instead of removing all those imports manually, React offers an automated script that will make everything for you:

npx react-codemod update-react-imports

Just be careful to have all your work committed, as it will create changes probably on almost every file of your repository.

What about linting?

There was another small problem. Eslint was complaining if one was removing React from a file, saying it was not a UMD global.

The missing piece is on this page, in a small note at the end of the page: the eslint rule to disallow missing React when using JSX.

At the bottom, there is a paragraph. If you are using the new JSX transform from React 17, you should disable this rule, adding "plugin:react/jsx-runtime" to "extends" in the eslint config file.

Now everything will work as expected and you will have a much cleaner codebase!

Thank you for reading! Let's connect on Twitter

Fixing Material UI and Emotion's handling of Transient Options

Alex — Tue, 31 Jan 2023 16:01:58 +0000

Passing Props to custom Emotion styles with Material UI

Photo by Amanda Vick on Unsplash

Recently I encountered an issue with the Material UI that I couldn't wrap my head around. What was happening?

Modern libraries for managing custom CSS, like Styled Components or Emotion, have accustomed us developers to the possibility to use styled elements as real, reusable components. They can even extend other styles or other components. CSS becomes building blocks like React, and that's just great.

Using Material UI means using Emotion. It works similarly to Styled Components, although the syntax is slightly different. One of the advantages of using these libraries with React is that you can pass them props and you can change the style according to their values.

However, it turns out that Emotion with Material UI lacks proper handling of this feature (as of now at least), which is called transient options. So if you pass a boolean value as a prop and use it like this:

  // component
  <MyStyledBox isdarktheme={true} />

  // style file
  import { Box } from '@mui/material'

  export const MyStyledBox = styled(Box)(
    ({isdarktheme}) => ({
      color: isdarktheme ? 'white' : 'black'
    })
  )

React will throw a warning saying: 'Received true for non-boolean attribute isdarktheme'. It will work, but the warning will stay.

How to fix it? I found that there's an issue opened with Emotion about this, and here's the best working workaround answer.

So here's how I followed it and implemented it. In one util file, I added:

  export const transientOptions: Parameters<CreateStyled>[1] = {
    shouldForwardProp: (propName: string) => !propName.startsWith('$'),
  }

This identifies the props starting with $ as transientOptions through the React hook shouldForwardProp. As the name says, it will allow the prop to be passed.

Then I can import the method and use it as an option for the emotion component. Here's with TS:

  import { transientOptions } from 'utils'

  type Props = {
    $isdarktheme: boolean
  }

  export const MyStyledBox = styled(Box, transientOptions)<Props>(({ theme, $isdarktheme }) => ({
    color: $isdarktheme ? 'white' : 'black'
  }))

The warning disappeared and the prop is correctly taken by Emotion.

Thank you for reading! Let's connect on Twitter or Mastodon!

Reduce your Jest tests running time (especially on hooks!) with the maxWorkers option

Alex — Thu, 08 Dec 2022 15:52:29 +0000

Photo by Josh Olalde on Unsplash

Many applications have hundreds (and sometimes thousands!) of tests. Sometimes those tests are run only manually; more often they're attached to some hook. For example, we can use 'husky' to run some action before the commit or the push. In my case, lint and prettier before the commit and tests before the push.
Or the tests can be run during some actions on a CI/CD tool.

I'm with a MacBook Pro 2020, and I've got around 170 unit and integration tests running on a frontend application. That means that at least half of it needs rendering the components many times - hence consuming much memory and CPU.

When I run my tests manually, they usually are pretty fast, around 1 minute and some seconds of execution time.
However, I found that when I'm pushing the code to our repository, many times the test suites fail on timeout. They exceed the default time limit of 5 seconds.

Of course, this limit can be increased. But if 5 seconds is not enough for running a test, there's something wrong!

Now, although Jest runs with Javascript (which is single-threaded), it uses workers to divide the workload among many Jest processes, imitating multi-threading.
Jest calculates -on many factors- how many workers can activate and runs them. In my case, there were around 8. When I was running them continuously, my laptop fan started running as if it was going to melt.

CPU got slower with the heating up and tests were starting to timeout because there was no more computational power to let them run properly.

Luckily, Jest let us customize this option with --maxWorkers.
On my CRA (Create React App) I added this option cutting in half the workers to the test command:

"test": "react-scripts test --maxWorkers=50%"

This lets just 4 workers be spun and let the tests pass without timeout issues. Their execution was anyway fairly quick, and it prevented me from any more trouble!
Of course, the option can be set even lower (or higher). It depends on many factors, so you can try and test yourself (pun intended)!

Thank you for reading! Let's connect on Twitter or Mastodon!

Finding a bug after writing a test, an example

Alex — Wed, 30 Nov 2022 15:56:04 +0000

Photo by Alan Emery on Unsplash

In almost every Sprint, at work, I try to reserve some space for solving tech debt and doing some refactoring. A part of resolving this debt is making integration tests. And sometimes it happens that those tests find some unknown bug. That's what happened a few days ago. As usual, the names of the methods and variables are just an example.

The page I was writing the tests on is a simple one. Some text, three buttons, and nothing more. Yet, it has some hooks as well, defining the logic of those buttons (opening another URL, submitting the form, etc).

I started writing the tests in the usual way, using React Testing Library. Checking the rendering and the behavior of the page by clicking on the different buttons. When I was writing the test for one of the three buttons, however, it forced me to let me think: is this button always visible? Why?

{showButton && (
   <Button onClick={onApplyClick}>
      DO THING
   </Button>
 )}

I checked the hooks and found out that it would render only when another property was true, or present. So why it was always there?

  showButton: !!secondaryProp,

I followed the source of that property and I came across the point where its data was fetched from the (easy-peasy) store, and then it was set as an initial value of 0, instead of being undefined.

const initialState: IState = {
  ...
  secondaryProp: 0,

The type of that property was just "number", instead of "number?". So it was always true.

export interface IState {
  secondaryProp: number

To fix it, I changed the type and set the initial values as undefined.

Re-checking that property I saw that another value was dependent on it being present or not. So in another hook, I had to redefine the behavior in case the prop was falsy.

const newUrl = secondaryProp && `${FETCHED_URL}/prop=${secondaryProp}`

const onClick = () => {
    if (!newUrl) {
      return
    }

    window.open(newUrl)
  }

So that's an interesting case of how making tests helps you reflect on what the behavior, and the logic of the methods and components, should be.

Thank you for reading! Let's connect on Twitter or Mastodon!

Make a reusable test with React Testing Library

Alex — Tue, 22 Nov 2022 19:34:42 +0000

Photo by Sigmund on Unsplash

It can happen to have very similar tests across our suites. In one of my recent examples, I had to test if the UI of the footer of the pages in the application was correctly rendered, depending on a prop change.

The footer consists only of a box with inside an SVG icon and a text. But those are white when we have a dark background, and dark gray when the background is white.

The logic is already in place, and the simple test steps would be:

render the page (component)
get the elements to check
check that the elements have the correct style.

The next -and boring- step would be placing this test inside each page test suite, and check for the color individually.

Instead, we can make a reusable test, like a normal function.
We can put it in some shared.js file so it can be picked up anytime.

import { screen, waitFor } from '@testing-library/react'

const testPageFooterWithColor = (renderPage, expectedColor) => {
  test('it checks that the footer is present and has the correct color', async () => {
    renderPage()

    const footerText = screen.getByText('our footer text')

    await waitFor(() => {
      expect(footerText).toBeInTheDocument()
    })

    expect(footerText).toHaveStyle({ color: expectedColor })
  })
}

export { testPageFooterWithColor }

Then we can import it in our suites:

  const renderCustomPage = () => {
    render(
      <CustomPage />,
      { wrapper: MemoryRouter },
    )
  }

  describe('our test suite', () => {
    ...our tests

    testPageFooterWithColor(renderCustomPage, 'white')
  })

Thank you for reading! Let's connect on Twitter or Mastodon!

Making reusable get methods in React Testing Library

Alex — Wed, 16 Nov 2022 15:47:37 +0000

Creating some abstractions to have ready to use getter functions

Photo by A.Z on Unsplash

While writing unit and integration tests, I'm trying to find the best way on how to write them cleanly.
I'm using React Testing Library so that makes already a good job of using good patterns.
However, recently I stumbled upon the fact that I'm reusing again and again the same methods to get the elements from the DOM.

The majority of cases are using screen.getByRole for the buttons and screen.getByLabelText for the inputs, using the name prop. The only difference would be the first returing the element, and the latter returning the value of the input. Normally, I would use the first one this way:

screen.getByRole('button', {name: /name of the button/i })

As I like to use the names without having to think about capitalization of some letter, I use the parameter 'i' with Regex in order to ignore this case. Also, being with Regex, I don't have to worry whether it's a full sentence or just a part of it.

So, I thought I could extract these methods in a more reusable way, in order to use them freely around the test suites.

Here's how I did it:

const getButtonByName = (btnName) => {
  const regName = new RegExp(btnName, 'i')

  return screen.getByRole('button', { name: regName })
}

const getInputByLabel = (label) => {
  const regName = new RegExp(label, 'i')

  const { value } = screen.getByLabelText(regName)

  return value
}

Then I can easily use them:

  const button = getButtonByName('my button')
  const inputValue = getInputByLabel('my input label')

I made another method in a similar way for radio buttons. More could be done but these are the three methods I use the most. So for the rest, it could be a little of over-abstraction.

Another improvement that can be done, in my opinion, would be change the strings of the names ('my button', etc.) with fixed objects (JS) or enums (TS). For example:

JS

const ButtonNames = Object.freeze({
    ButtonOne: "button one",
    ButtonTwo: "button two",
})

TS

enum ButtonNames {
  ButtonOne = "button one"
  ButtonTwo = "button two"
}

Thank you for reading and let's connect on Twitter!

Memoize a React component

Alex — Thu, 25 Aug 2022 12:29:29 +0000

Memoization is a feature in React. The library compares (in a shallow way) two versions of an object and, if they are the same, does not re-render (or recompile) it, creating an optimization in performance and memory.

The React.memo higher order component (to notice, not useMemo) used on a component is very easy to implement, but it's not always efficient or necessary. As everything about memoization in React, we shouldn't memoize everything but just the objects that are heavy, big, or re-renders very often.

So in my job it happened an interesting case. I had quite a big parent component that is wrapping inside smaller children components. I'll just change the type of subjects and component name, but the example I'm giving is the same I have.

How do we memoize a component?

Supposing we have:

  const BigComponent = ({...lots of props}) => {...lots of stuff done}

then we just put memo on the export

  export default memo(BigComponent)

Is it enough? Sometimes yes. But the more interesting part is another. How does React knows what to compare? It takes a previous version, and a next version (the one we're updating with new props). In the same way, memo could use those two version as callback arguments. They can be checked to make a quicker comparison, speeding up even more the memoization process.

Supposing that our BigComponent is mostly managing a school student card, and we have the children components showing according to the student. Then we'll have BigComponent supposedly changing when the id of the student change (supposing that is mapped from a parent component).

  const BigComponent = ({student, ...other props}) => {...lots of stuff done}

We can now memoize the component comparing the IDs of the student. We can think of the IDs as the keys of the object. If they're the same, the component will remain the same, otherwise it will re-render.

But as you can see, I've done it slightly differently!

  export default memo(BigComponent, (prev, next) => prev.student.id !== next.student.id)

This above will say: if the previous ID is different comparing to the next one, return true. The problem here is that we're getting the props and we use them on a child component, so if the IDs are the same (===) it won't do anything (won't open the card).

In my case, it checks that the IDs are different, and don't do anything. But if they're the same, it'll allow the rerender. It's similar to how ShouldComponentUpdate was working, as we're giving the condition on when to rerender.

So, to sum up, we're memoizing (not rerendering) this component the opposite way only when the IDs (keys) change. That means that when we open a student card it will rerender. But when we add more students, or we use other student cards, they won't rerender in the page, and we will be getting a performance improvement.

Sending validation errors through a Formik form

Alex — Fri, 05 Aug 2022 11:29:00 +0000

When we need to validate a Formik form (often with Yup) we can use the following method: validateForm.
It returns a promise so we have to check if it resolves or not.
However, the validation errors are sent directly inside the promise as an argument and not caught. So the promise is always resolved in this case.

To pass the validation error, then, we have to pass the errors as an argument of the promise itself.

  formik.validateForm({...})
    .then((errors) => submit(formik, values, errors))

Then the errors can be checked and the logic can be written in the submit method.

const submit = (formik, values, errors) => {...}

Bonus: here are the types (for TS users) for the 3 arguments above:

formik: FormikContextType<FormikValues>
values: FormikValues
errors: FormikErrors<FormikValues>

Thank you for reading, and let's connect on Twitter!

Epic React: Hooks. UseState, useEffect. What I'm learning..

Alex — Wed, 23 Mar 2022 15:11:07 +0000

Back into Epic React
1 - useState
2 - useEffect
Other notes

Back into Epic React

After a long break and quite more experience, I managed to get back to EpicReact. This is the second chapter of the series. Here's the link to the first one:

Epic React. Fundamentals. What I'm learning.

As in the other post, this isn't a guide to React nor to EpicReact. They are just my notes, thoughts and learning on the course workshops. Few things can appear as confusing for lack of context. However, I hope you can find some interesting points to reflect upon. Repositories and solutions are anyway publicly available on Kent's Github.

Let's dive into hooks, with a focus on useState and useEffect!

1 - useState

A first good point is: in controlled components value is changed/updated by the state and uncontrolled by event handlers.

The interesting part of useState is how under the hood is nothing else but an array declaration. When it's used, it gets two elements of the array, in which the first is the variable and the second one is the function to update the variable.

So a code like this:
const [ count, setCount ] = useState(0)
would be, not destructured:

const array = useState(0)
const count = array[0]
const setCount = array[1]

The first exercise is quite simple if one understands React states well. Every time (unless different specified) the state changes, in any part of the component, there will be a re-render of the component virtual DOM, updating what appears on the page.
If I call a function on the onChange in the input, and that function changes the state (setCount(event.target.value)), then I can call the updated state in any part of the render
{count ? <strong>Count is {count}</strong> : 'Add a number to count'}

In the second part the task would be to use a prop in the component as initial value to pass
<Counting initialCount={0}
I find there are different ways. The best way is to setState to that initial value that is destructured in the function arguments:

function Counting({ initialCount = 0 })

Destructuring is necessary because initialCount is an object so, if we're passing the argument just like it (initialCount), the result will be [Object object].
The default value (= '') is also necessary in case we don't pass anything as a prop. In this case we don't cause a crash because of undefined value (unless we use Typescript and we define it as possible undefined).
So one way is to setState(initialCount) and value=count in the input.

Another possible way is to set the defaultValue of the input to the initialCount. This will have the same effect except that the state of the rendered text won't be updated until something is typed. It's possible to create a check to use the count (like a nested if but with ternary operator). However, it will make the code more difficult to read and follow in its flow.

2 - useEffect

This hook is called at every render of the component whenever its dependencies change. Or at any render if the dependency array is empty.

We can persist the state: call the localstorage methods inside useEffect (getter and/or setter) const [name, setName] = React.useState(window.localStorage.getItem('name') || initialName)
However in doing so we can run into a performance issue. Access to localstorage is slower than other methods.

There are some workarounds for this:

React’s useState hook allows you to pass a function instead of the actual value, and then it will only call that function to get the state value when the component is rendered the first time: React.useState(() => someExpensiveComputation()) ... that's the same as the callback on setState in class components const [name, setName] = React.useState(() => window.localStorage.getItem('name') || initialName) If we put a console inside the callback we cans see it's called only on the first render. It should be used only for bottleneck functions that require sync time

Or using useEffect:

lazy initialization, or not reading from localStorage at every render.
dependency array: second argument on useEffect which signals to React that your effect callback function should be called when (and only when) those dependencies change:

React.useEffect(() => {
    window.localStorage.setItem('count', count)
  }, [name])

If other states apart from name change setItem won't be called
If left empty, it'll be called only at the first render.
The state in the dependency array is an object that is compared on the render with the previous state through object comparison. If they're the same useEffect won't run , otherwise yes.

Custom hooks. They are external functions called inside a method. Their names start with ”use”.
If we have different functions inside the component method we can externalize those, even useEffect:

If we have a method like this:

function Greeting({ initialCount = 0 }) {
  const [count, setCount] = React.useState(
    () => window.localStorage.getItem('count') || initialCount,
  )

  React.useEffect(() => {
    window.localStorage.setItem('count', count)
  }, [count])

  function handleChange(event) {
    setCount(event.target.value)
  }

We can convert it to this and then use it in the main method as custom hook:

function useLocalStorageWithState() {
  const [count, setCount] = React.useState(
    () => window.localStorage.getItem('count') || initialCount,
  )

  React.useEffect(() => {
    window.localStorage.setItem('count', count)
  }, [count])

  return [count, setCount];
}

function Greeting({ initialCount= 0 }) {
  const [count, setCount] = useLocalStorageWithState()
  function handleChange(event) {
    setCount(event.target.value)
  }

Other notes

Setting up a callback inside useState makes the setting of the state as lazy, as it compares the states and doesn't change it if it's the same.
If you ar getting an error that goes like: 'React Hook ... is called in function ... which is neither a React function component or custom React Hook function', then it's possible that you put a wrong name to the custom hook.
As a React convention, your function should start with 'use' and probably is not. For example, useGetItems.
So, instead of syncLocalStorageWithState, we call it useLocalStorageWithState.

useLocalStorageWithState should have the same use as the useState hook, so it can return an array like useState, and we can store it in a similar array. So we have created a custom useState hook that does other stuff as well.
We pass as well count and initialCount as parameters useLocalStorageWithState(count, initialCount) and then making useLocalStorageWithState more generic, receiving as arguments key, defaultValue , so the method can be reused freely and not stay chained to a count state. The same applies to the state. We can set [state, setState] and return the same.
Having two arguments means that also useEffect should have two in the dependency array.

The logic of the flexible localStorage hook is the following:

get the item from local storage
if present, JSON parse it and return the result
if not, return the default value

That's for getting the state. For setting the changes using useEffect -in this case for creating/editing the local storage- se can move forward like this: once the state changes we can just stringify whatever the state will be and store it.
Serialize will be for stringify the JSON, while deserialize for parsing it.

In case as argument of useLocalStorageWithState, instead of a number, we'll pass a function, it's possible to create a check to return the results of another function.
const [name, setName] = useLocalStorageWithState('name', complexCounting() ) --> pass a function as default value
return typeof defaultValue === 'function' ? defaultValue() : defaultValue; --> return to useState the result of the method

Then it comes the complicated part.
In the above case, we are passing two parameters to useLocalStorageWithState. The first one -the key- is a string and the second a primitive value or a method.
What if somebody wants to pass another value to the 'key'? Now, for example, can be passed 'count' as string, but maybe somebody will want to pass something different (to store a different thing in local storage, for instance).

There's no direct way to change the state of the key, so what could be done is storing the key into a variable that won't trigger the render, using useRef. Following that, in useEffect we can compare the old key with the new one.

According to the docs:

useRef returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.
Note that useRef() is useful for more than the ref attribute. It’s handy for keeping any mutable value around similar to how you’d use instance fields in classes.

The difference with useState is then that useRef doesn't trigger a rerender, so with this hook we can actually set the key without triggering the rerender. The purpose of this is clear in the useEffect

const prevKey = prevKeyRef.current;
    if (prevKey !== key) {
      window.localStorage.removeItem(prevKey)
    }

Usually we store in localStorage a value. But this value is in an object, and that object has a key. So for now it's 'count'. But if it will be 'sum', and we don't remove the initial key, we'll have two objects in localStorage. So if the new key and the old one, which is stored in the useRef var, is different, we will remove the object in localStorage with the old key.