When coding in a declarative style, you only need to define how you want your data to look and the computer will do it for you.

React gives us JSX and hooks for that. 

JSX brings HTML into JS. You just tell React how your UI should look, and he takes care of every document.createElement , document.querySelector(...)[...] = ... and all that fun stuff for you.

Ever wondered why a component can only return one element? Because that element will become the root of your component that React will diff check to see if the UI change and he should appendChild something or setAttribute other.

How do hooks know to return the correct state?

Unlike class components, functions don't hold state (let's not talk about ... this 😨) . But React has to save your state or the previous values of your useEffect deps somewhere. We can cheat a bit by creating a closure around your component that holds these. 

Now how we retrieve those values? Here come those rules of hooks. That closure holds a hook call counter. You call a hook, it gets id'd by the current counter value, the counter goes up. So if hooks don't get called in the same order each time, that id system breaks.

A component is an indivisible, reusable parts of your code. We use them to better organize our ui, implement separation of concerns and avoid code duplication. But React also likes when we use them smart.

When something changes in your app and a re-rerender is triggered, that update doesn't end up straight in the DOM. Updating the DOM many times sequentially would be too slow.

React keeps a copy of the DOM in memory. That is fast to update. Also, when a component changes, React will update only the sub-tree of that component. 

When the update flood is done, boom, only one update to the real DOM. 

I just said that React doesn't immediately commit updates to the DOM because they are slow. Sometimes though, even in memory updates can be slow.  Traditionally, rendering is blocking. Once a render starts, it can't be stopped. This can delay a DOM update by too much making the experience choppy

Let's take as an example a search box that shows results while you type. After you press a key, at some point, React will have to start to render the updated results list. In that time, it can't also work on updating the text input. Thus, the typing feels choppy

React 18 will support some new awesome features that will help us overcome these issues.

1. Suspense
2. Transitions
3. Streaming HTML and Selective Hydration

If your component needs async data, you will either have to

• Implement some really rigid logic for each and every component
• Show incomplete UI
• Re-render all your UI when the data is ready

This is where Suspense comes in. Wrapping a component in Suspense will tell React that it will have to Suspend the rendering at some point to wait for some data. But it will try to render as much of the UI as possible. As data comes, it will render more of the UI. And in the end, you will get your DOM painted faster since most of the work was done while waiting for the network.

Here is another one. You press a button that takes you to another screen. You start fetching the data for that screen. In the meantime, a white screen or maybe a spinner. 

But why. Why did the developer made you see that other screen if it wasn't ready to be shown. Well... because they couldn't tell React that.

With the transition API they will be able to do just that. This allows us to tell React to wait for a suspending compoent to be done rendering (with a timeout) until it commits a state update, thus delaying any undesirable loading states.

React 18 brings huge improvements to server side rendering. Now when performing SSR we have to 

1. Wait for all the data to be fetched
2. Wait for the server to render the whole page
3. Display the rendered page
4. Wait for the whole page to be hydrated

Too much stuff to do at once and wait for. We could do one better. We could partially render the page on the server when data starts coming in and start streaming the page to the client. This way, the client can start hydrating parts of the page and show parts of the UI to the user while the server finishes the heavy work in the background.