How React Component Libraries are Changing
Tags: webdev, react, opensource, nextjs
Published: 2023-10-31 11:33:54

## Quick Overview of SSR

Lately, you may have heard about the rise of Server-Side Rendering (SSR) components in React, particularly if you are coming from the Next.js ecosystem. This change is reshaping how we use and interact with React Component Libraries.

If you’re transitioning from the Page Router or the core React application, you’re likely accustomed to rendering applications on the client side. This implies that all the calculations, processing, and data fetching occur on the client. However, things are evolving rapidly, primarily due to [React Server Components](https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components).

While there are numerous articles and videos available for a more in-depth understanding of React Server Components, here’s a brief overview: it allows us to render components on the server, encompassing all calculations, processing, and data fetching on the server side. The client only receives HTML and CSS, which should result in faster page loading speeds and an improved user experience for your customers.

## The Problem

However, there’s a catch: if you’re using hooks in a component, that component must be designated as a client component. React hooks cannot be rendered on the server since the API is unavailable there. To address this, you’ll need to annotate these components with the `“use client”` keyword. Once you’ve marked a parent component with this keyword, all its child components will be rendered as Client Components, even if they aren’t utilizing hooks.

But how is all this affecting the React Component Libs?

Check out this example on `Chakra-UI` docs -

```tsx
// app/page.tsx
'use client'
import { Link } from '@chakra-ui/next-js'

export default function Page() {
  return (
    <Link href='/about' color='blue.400' _hover={{ color: 'blue.500' }}>
      About
    </Link>
  )
}
```

As you can see, even for just a simple link, we must use the `“use client”` keyword. This is also required in the `page.tsx`, which implies that all components within this file will be client-rendered, potentially negating the advantages of the Next.js 13 App Router.

One might argue that you could create a separate component for this Link Component to eliminate the need for using the `“use client”` keyword in the main page file. However, this approach could lead to creating numerous components solely to avoid using the `“use client”` keyword, which may not be practical in the long run.

### This is not a solution, This is a hack!

The crux of the issue lies in the necessity of adding the `“use client”` keyword to all components. However, the challenge is exacerbated by the bloat that some libraries exhibit due to their architecture and underlying foundations. Notably, libraries like Chakra UI, MUI, and Ant Design handle this challenge with varying degrees of success.

A substantial portion of this bloat can be attributed to the libraries’ use of providers, such as `ThemeProvider`. Over time, these providers have grown in size and weight. As a result, building large applications with these libraries becomes increasingly complex and resource-intensive, particularly in cases like creating a data-rich dashboard or a substantial form with more than 50 fields, essentially a sizeable component on a single page.

## The Solution - *Micro Context Components*

By simplifying the context of components to their core functionality, we can reduce this overhead and develop lightweight applications. This transformation is made possible by libraries and tools like TailwindCSS, Radix UI, Adobe Aria, and many others.

Instead of relying on a `ThemeProvider` to handle light and dark modes, we can leverage TailwindCSS. When it comes to creating components, Radix UI allows us to build accessible UI components. Additionally, we can establish micro-contexts on top of them to manage props related to sizing and color schemes.

By adopting these approaches, we can cut our application’s size in half, enhance accessibility, and improve speed, all without any compromises.

There are tons of lib that are built to solve these problems and you can start using them right away - 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gfe3hpwrzx5eq97a3g1d.png)

1. [Rafty UI](https://rafty.rhinobase.io) (Created by Me 😁)
2. [Radix Themes](https://www.radix-ui.com/)
3. [Daisy UI](https://daisyui.com/)

and many more.

## Conclusion

React is a fantastic framework for building applications due to its extensive ecosystem and the high demand from companies seeking React developers. However, things can quickly get out of hand if not managed properly. These libraries can help prevent you from making common mistakes by offering lightweight components.

Rafty UI effectively addresses this issue by leveraging readily available tools like TailwindCSS and Radix UI, resulting in a very shallow learning curve. In fact, you can get started with it in just a few hours and create impressive applications. I’ve been using it for a while now, and it’s truly remarkable how compact and lightning-fast my applications have become.

*Do let me know what you guys think about [Rafty UI](https://rafty.rhinobase.io)!*

If you have any questions, do let me know and I will be happy to answer.

**Disclaimer** - As of right now, this is the scene as per best of my knowledge, but with the ever-changing world, these Libs might come up with some amazing solutions but nothing like that seems to be happening soon. Right now things seem to be moving towards the **Micro Context** based React Component Libs.

Let me know what you all think, in the comments.