
**React Server Components** are one of the most talked topics in the React
community right now.

They are a new way to build React apps that will be released in the future. They
are not yet available, but we can already start to learn about them.

They were first introduced as an **RFC (Request for Comments)** in
December 2020. Here is the blog post, where they were introduced as a current
research:
[Introducing Zero-Bundle-Size React Server Components](https://beta.reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components)

And here is a link to the RFC, which is super interesting to read, to get the
idea behind them and how the concept developed since then:
[RFC: React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md)

Dan Abramov, one of the React core team members, has been putting a lot of
effort into educating everybody on Twitter and answering questions about them.

He recently met up with Kent C. Dodds and Joe Savona, whos Tech lead in the
React organization in Meta. I totally recommend to watch the whole video:
[React Server Components with Dan Abramov, Joe Savona, and Kent C. Dodds](https://www.youtube.com/watch?v=h7tur48JSaw&t=427s)

They tried to answer all of Kents' questions about React Server Components and
there was a lot of insights to be learned.

In this post I want to summarize the most important things I know about React
Server Components so far.

In the future, we'll be able to differentiate between **Server Components** and
**Client Components**. Both will have different abilities and limitations. Let's
take a look on the things they can do:

### Server Components

- can directly access server data
- can use this data to generate html and return it to the browser
- read data on the server, pass it down by props
- each component can fetch the data that it needs
- they can hand of the rendering to the client by importing and rendering a
  "client" component
- includes the server into the unidirectional data flow
- maybe we don't need to build APIs anymore, when using server components
- they can't use state or effects
- they can't use browser-only APIs like the DOM
- help to reduce the bundle size, by giving us the ability of shifting
  third-party dependencies to the server

### Client Components

- are inside the server components
- can be interactive JSX components
- HTML created at runtime in the browser from JavaScript
- are marked with 'use client' at the top and therefore only included in the
  bundle if they are used
- can use state, effects, lifecycle methods, custom hooks
- the components we are already used to

To fully understand this new separation, lets take a look at a simple example:

```ts
// server
import db from './db'
import UserDetail from './UserDetail'

export const User = () => {
  const user = db.getUser(id)
  return <UserDetail user={user} />
}
```

```jsx
// client
'use client'
export const UserDetail = ({ user }) => {
  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  )
}
```

In this example, the server component `User` fetches the user data from the db
and passes it down to the client component `UserDetail`. The client component
then renders the HTML.

This is a very simple example, but it shows the basic idea of how server and
client components work together.

The split between server and client components will enable us again to **take
full advantage of the server**. By shifting several main tasks, like data
fetching, to the server, we can **reduce the bundle size** and **improve the
performance** of our apps.

I'm very curious to see how this will work in practice. I think it will be a big
step forward for React and the whole ecosystem. And maybe a totally new way to
build web apps in the future.


Today I learned about React Server Components, what they are and how they will be useful.

React Server Components


If you've worked with React you've possibly done something like this to fetch
data from an API:

```js
const [data, setData] = useState(null)

useEffect(() => {
  fetch('https://pokeapi.co/api/v2/pokemon')
    .then((res) => res.json())
    .then((data) => setData(data))
}, [])
```

With the release of React 18 a lot of people were wondering if this is still a
good practice. The confusion stems from the fact that React 18 renders
everything twice in strict mode in development.

In this react thread on the react subreddit, Dan Abramov, a member of the React
core team at meta, shares a lot of valuable information on this topic:

[What is the recommended way to load data for components in React 18?](https://www.reddit.com/r/reactjs/comments/vi6q6f/what_is_the_recommended_way_to_load_data_for/)

Here are the **key takeaways** from his post:

- Running effects twice shouldn't break your code. You should always ignore
  stale responses. If it does break your code, you have race conditions to fix.
  One way to do this, is to implement a cleanup function. This article offers a
  great explanation on how to do this:
  [react docs: fetching data](https://beta.reactjs.org/learn/synchronizing-with-effects#fetching-data)

* If you can, switch to server-side data fetching. Next.js and Remix both offer
  built-in solutions to deal with that, which are better suited than client-side
  data fetching in effects. If a server-side framework isn't an option, consider
  using a client-side cache like [React Query](https://tanstack.com/query/v4/)
  to fetch data.

**A final note:** these changes have nothing to do with the release of React 18.
In fact, these issues have existing much longer. The react team just started
documenting them now. The main issue here is, that we may have all used effects
like useEffect wrong the whole time.

I've already wrote about that topic on other posts like my blog post
[the mistakes I made using React](/blog/the-mistakes-i-made-using-react/) and my
Today-I-learned post:
[missusing useEffect](/today-i-learned/missusing-use-effect/).

Now's a great time to refactor and apply the changes mentioned above.


Today I learned, about the best way to handle data fetching in React 18.

Data fetching in React 18


Today I learned that Reacts `useEffect` is not meant for data fetching and is
not a state setter either!

This questions all my best practices I’ve applied over the last years since we
got useEffect.

David K. Piano held this amazing talk about
[our wrong understanding of useEffect](https://www.youtube.com/watch?v=Ck-e3hd3pKw&)
and what the alternatives are. So, good bye useEffect?

His key takeaways were the following:

- the default behaviour of `useEffect` is an infinite loop
- `useEffect` is not for effects
- `useEffect` is not a lifecycle hook
- `useEffect` is not a state setter
- `useEffect` should actually be called `useSynchronize`, because it's meant to
  synchronize React with external systems


Today I learned that Reacts useEffect is not meant for data fetching and is not a state setter either!

Missusing useEffect


In a project I worked on recently someone mentioned it would be cool to have
some **confetti** after a **form submission**. I loved this idea and after a
quick research I discovered
[canvas-confetti](https://www.npmjs.com/package/canvas-confetti).

Really cool and easy to use plugin to implement some confetti to celebrate!

If you're working with React, there is even a
[React component](https://www.npmjs.com/package/react-canvas-confetti) for this
library.

Here's a small example, where you can see it in action:
[fireworks](https://codesandbox.io/s/fireworks-fn-react-canvas-confetti-w594u?file=/src/App.js).


Confetti


While
[Suspense for Data fetching](https://reactjs.org/docs/concurrent-mode-suspense.html)
is still an experimental feature in React and is not yet available in a stable
release, React 16.6 also added a `<Suspense>` component.

This `<Suspense>` component lets you specify the loading indicator in case some
components in the tree below it are not yet ready to render.

This is a super cool and easy way to add a loading state with a loading
component to your React application.

Here is a simple example:

```javascript
import * as React from 'react'
import { LoadingComponent } from './loading-component'

const ComponentWithAsyncData = React.lazy(() =>
  import('./component-with-async-data')
)

const App = () => {
  return (
    <React.Suspense fallback={<LoadingComponent />}>
      <ComponentWithAsyncData />
    </React.Suspense>
  )
}

export default App
```

While the `<ComponentWithAsyncData />` may not be ready to render yet because
it's still waiting for an API Request, React.Suspense will handle that and show
our `<LoadingComponent />` instead.

What's even cooler, is that React can also lazy load the component with the
async data by using `React.lazy`. So it's not even imported, until it's ready.
Awesome!

You rean read more about it in the
[official React docs](https://reactjs.org/docs/react-api.html#reactsuspense).

So that's what I learned today. What about you?

Just send me an [email](mailto:marco@marcoheine.com) or message me on
[twitter](https://twitter.com/home) about your learnings. I would really like to
here from you!


React Suspense Lazy Loading Components


Today I learned from Dan Abramov how to persist the redux state to the local
storage.

Learn more:
https://egghead.io/lessons/javascript-redux-persisting-the-state-to-the-local-storage


Persisting redux state with localStorage


The React Hook useMemo ist not the solution for all your performance problems.
In most cases memoizing costs more CPU power than not doing it.

Learn more: https://kentcdodds.com/blog/usememo-and-usecallback


Performance and useMemo


React-Router introduced new hooks with its release of version 5: useHistory,
useLocation, useParams and useRouteMatch.

In my opinion, these new hooks make working with react-router even more convient
and maintainable, so if you have not updated to using them yet, give it a try!

Learn more: https://css-tricks.com/the-hooks-of-react-router/


Today I learned