DEV Community: Amir

Downsides of Passing object as `useState` hook value.

Amir — Sun, 27 Aug 2023 20:05:22 +0000

In this article, I'll talk about using objects with the useState hook. there are downsides to this approach. To explore this, let's consider a pagination component as an example. Although I'm using pagination here, similar considerations apply to other cases like when working with the useState hook. Imagine we have a <Pagination/> component.

Let's use it inside of the screen that you want to have a pagination.

  function Screen() {
     const [pagination, setPagination] = useState({
         ... data // bring some defautl data from some where.  
     }); 

     // bringing other pagination related functions in the body of this component

     return ( 
        <div> 
           <Pagiantion {...pagination}/>
        </div>
     )
  }

Is this logic related to pagination functionality reusable? The answer is "No." This is because the reusable logic is placed on the consumer side. To reuse it, you would need to copy the code from the component and paste it elsewhere. This might sound straightforward, but it's not ideal. By encapsulating all the pagination data within an object, maybe people might miss the opportunity to create a reusable custom hook named usePagination.

This is one of the main reasons why I believe using objects as values for the useState is problematic. When we use an object as the value for the useState hook, we miss out on a significant chance for reusability. So, what's a better approach? The solution lies in writing a custom hook.

Let's take a step further and imagine that we've decided to implement a custom hook. However, even in this scenario, we continue to use an object for the useState hook. The code snippet below illustrates 2 version of the implementation of the usePagination hook.

export const usePagination = (paginationProperties) => {
  const [pageLimit, setPageLimit] = useState(paginationProperties?.pageSize || 40);
  const [current, setCurrent] = useState(paginationProperties?.currentPage || 1);
  const [hasNext, setHasNext] = useState(paginationProperties?.hasNext || false);
  const [hasPrevious, setHasPrevious] = useState(paginationProperties?.hasPrevious || false);
  const [totalPages, setTotalPages] = useState(paginationProperties?.totalPages || 0);
  const [totalCount, setTotalCount] = useState(paginationProperties?.totalCount || 0);

  const nextPage = () => {
    if (hasNext) {
      setCurrent((current + 1) % (totalPages + 1) || 1);
    }
  };

  const previousPage = () => {
    if (hasPrevious) {
      setCurrent((current - 1 + totalPages) % (totalPages + 1) || totalPages);
    }
  };

  const skipBack = () => setCurrent(1);  

  const skipForward = () =>  setCurrent(totalPages);

  const resetPagination = () => {
    setPageLimit(10);
    setCurrent(1);
  };

  const goToPage = (pageNumber: number) => {
    setCurrent(pageNumber);
  };

  // return everything that Pagination component needs to work with 
  return ...; 
};

export const usePagination = (paginationProperties) => {
  const [pagination, setPagination] = useState({
    pageLimit: paginationProperties?.pageSize || 40,
    current: paginationProperties?.currentPage || 1,
    hasNext: paginationProperties?.hasNext || false,
    hasPrevious: paginationProperties?.hasPrevious || false,
    totalPages: paginationProperties?.totalPages || 0,
    totalCount: paginationProperties?.totalCount || 0,
  });

  const nextPage = () => {
    if (pagination.hasNext) {
      setPagination(prevPagination => ({
        ...prevPagination,
        current: (prevPagination.current + 1) % (prevPagination.totalPages + 1) || 1,
      }));
    }
  };

  const previousPage = () => {
    if (pagination.hasPrevious) {
      setPagination(prevPagination => ({
        ...prevPagination,
        current: (prevPagination.current - 1 + prevPagination.totalPages) % (prevPagination.totalPages + 1) || prevPagination.totalPages,
      }));
    }
  };

  const skipBack = () => setPagination(prevPagination => ({
    ...prevPagination,
    current: 1,
  }));

  const skipForward = () => setPagination(prevPagination => ({
    ...prevPagination,
    current: prevPagination.totalPages,
  }));

  const resetPagination = () => {
    setPagination(prevPagination => ({
      ...prevPagination,
      pageLimit: 10,
      current: 1,
    }));
  };

  const goToPage = (pageNumber) => {
    setPagination(prevPagination => ({
      ...prevPagination,
      current: pageNumber,
    }));
  };

  // return everything that Pagination component needs to work with 
  return ...;
};

Let's delve into the drawbacks of using an object as the useState value:

complexity:
Let's compare the complexity of both hook versions and see which one is clearer. Clearly, the first version is more straightforward. Some argue that using an object as the hook value makes code tidier by consolidating related data. However, I find this less compelling. The usePagination hook, as its name suggests, should handle all relevant aspects. As the state object grows, managing and debugging can become more intricate. Another option is to use the useReducer hook, designed for situations where states need to be collocated.

Immutability:
When you're using the setState function or its equivalent with an object as the value, it's crucial to ensure immutability while updating a single property within that object. Sometimes, individuals resort to third-party libraries like 'Immer' to simplify managing immutability during updates. do you need another package for just updating your state ?

Shallow Comparison:
React's default behavior for comparing state updates involves shallow comparisons of objects, which might lead to unexpected behavior if not managed carefully.

Performance:
While using objects can be performant for many cases, extremely large or deeply nested state objects might impact performance.

In conclusion, using an object as the useState value in React might make your code look organized and readable, but it can be misleading. This method might hinder your ability to create custom hooks and understand your components' needs fully. You could miss chances to make your code more reusable.

Moreover, this approach requires you to carefully think about aspects like complexity, immutability, and potential performance issues. It's crucial to understand the downsides of using an object with useState.

First step to SSR and HTML First

Amir — Sun, 13 Aug 2023 11:58:01 +0000

If you're here because of the catchy title, that's great! I'm all for prioritizing HTML-first development in web apps. This article is about how I like building web applications.
I think making web applications with server-side rendering is usually the right approach. But for apps like Figma or those needing a lot of interactivity, it's better to render them on the client side.
The main focus of this article is on the React UI library. However, the concepts discussed here can also be applied to other libraries or frameworks like Solid.js, Vue.js, and more.

As all of us know React is an UI library and that means that components in our application should be only in charge of rendering content not fetching and doing server actions ( react is not a data library). we should use a ssr framework ( remix, next.js) or writing our own framework :)
but what about existing csr applications out there? should we rewrite them?
I think “NO”.
There are two solutions to consider. The first solution involves rewriting the application from scratch while reusing as much code from the client-side rendering (CSR) project as possible. Personally, I strongly disagree with this approach, and my reasons are straightforward. Firstly, there might be limitations in terms of available resources and developers to undertake a complete re-creation of the application. Secondly, rewriting essentially means not leveraging the existing codebase, which strikes me as counterintuitive.

Now, when is starting from scratch a viable solution? It becomes a reasonable option when there's virtually nothing that can be repurposed or reused from the previous project.

The second solution involves partially updating and refactoring the code to align with our objectives.

Should people that satisfied with the CSR follow this article yet? the answer is YES.

most probably in the CSR applications out there you use useEffect to fetch your data or you are using a library that doest that for you, so you shouldn't do that any more. by following this article you will find the solution.

Many React applications use the react-router-dom library. The creators of this library have made changes and provided steps to prioritize an HTML-first approach. This makes it easier to switch to a server-side rendering (SSR) framework if you plan to, or it ensures you're using React correctly even if you're not migrating.

What are these steps? To start, ensure you have react-router-dom version 6.4.

In this version, each route features a property named loader. This property allows us to attach our fetch function specific to that route.

example:

<Route
  path="/"
  loader={async ({ request }) => {
    // loaders can be async functions
    const res = await fetch("/api/user.json", {
      signal: request.signal,
    });
    const user = await res.json();
    return user;
  }}
  element={<Root />}
>
<Route
    path=":teamId"
    // loaders understand Fetch Responses and will automatically
    // unwrap the res.json(), so you can simply return a fetch
    loader={({ params }) => {
      return fetch(`/api/teams/${params.teamId}`);
    }}
    element={<Team />}
  >
    <Route
      path=":gameId"
      loader={({ params }) => {
        // of course you can use any data store
        return fakeSdk.getTeam(params.gameId);
      }}
      element={<Game />}
    />
  </Route>

Now, let's address the process of fetching data for use within a component. The router team has introduced a hook known as useLoaderData. As shown in the example below, you can utilize this hook to fetch data specific to the path.

function Root() {
  const user = useLoaderData();
  // data from <Route path="/">
}

function Team() {
  const team = useLoaderData();
  // data from <Route path=":teamId">
}

function Game() {
  const game = useLoaderData();
  // data from <Route path=":gameId">
}

Picture this: you're preparing to render a page featuring comments, history, and issue information. The key objective is to guarantee that the issue-related data is present when the page is displayed, eliminating the need for loading spinners or placeholders. To achieve this, we should await the data fetch. However, for comments and history, it's preferred to wait until the data is loaded before showing a spinner (or placeholder). The code example below provides a example that how it's going to be done:

<Route
  path="issue/:issueId"
      element={<Issue />}
      loader={async ({ params }) => {
        // these are promises, but *not* awaited
        const comments = fake.getIssueComments(params.issueId);
        const history = fake.getIssueHistory(params.issueId);
        // the issue, however, *is* awaited
        const issue = await fake.getIssue(params.issueId);

        // defer enables suspense for the un-awaited promises
        return defer({ issue, comments, history });
    }}
/>;

function Issue() {
  const { issue, history, comments } = useLoaderData();
  return (
    <div>
      <IssueDescription issue={issue} />

      {/* Suspense provides the placeholder fallback */}
      <Suspense fallback={<IssueHistorySkeleton />}>
        {/* Await manages the deferred data (promise) */}
        <Await resolve={history}>
          {/* this calls back when the data is resolved */}
          {(resolvedHistory) => (
            <IssueHistory history={resolvedHistory} />
          )}
        </Await>
      </Suspense>

      <Suspense fallback={<IssueCommentsSkeleton />}>
        <Await resolve={comments}>
          {/* ... or you can use hooks to access the data */}
          <IssueComments />
        </Await>
      </Suspense>
    </div>
  );
}

function IssueComments() {
  const comments = useAsyncValue();
  return <div>{/* ... */}</div>;
}

Fetching data on the page is the initial and vital step towards moving to server-side rendering. Even if you're not sure about switching to server rendering, this step is essential. Remember, React is for UI, not data fetching in components.

Next comes handling data mutations, a task separate from components. React is mainly for UI, not data.

Lastly, the examples in this article are from the react-router-dom documentation. For more details, explore the documentation. The main point here: React isn't meant for data handling.

in case you had question or you wanted to discuss furtur feel free to text me on X(Twitter): https://twitter.com/AmirArsalan_Az