React 19 Is Coming!

00:00:00: The React team shared an update with

00:00:03: us, which is pretty exciting for a couple

00:00:06: of reasons.

00:00:07: The first reason is that it's been some

00:00:10: time since we received at least an official

00:00:14: update, I guess, if you define official as

00:00:17: the React blog.

00:00:19: That's of course not entirely true,

00:00:22: because the React team does also

00:00:24: communicate on other channels, for

00:00:26: example on X, but of course also

00:00:30: because a lot of React development

00:00:33: recently happened in the context of

00:00:37: Next.js or at least was communicated in

00:00:41: the context of Next.js, but I'll get back to

00:00:44: that.

00:00:44: So it's pretty exciting because the last

00:00:47: official blog post we got on the React

00:00:50: blog was on May the 3rd, 2023, so almost

00:00:55: a year ago, and now on February 15th,

00:00:59: 2024, we got another blog post, another

00:01:02: update and a pretty exciting one,

00:01:04: because in this update we learn a lot

00:01:07: about the relatively near future of React,

00:01:11: about React version 19, which will be the

00:01:14: next major version of React, and about

00:01:18: some exciting features that will be

00:01:20: included in that version.

00:01:22: In addition, there is the announcement, I

00:01:25: guess, of React Conf 2024, which is

00:01:28: scheduled for May 15th and 16th this

00:01:32: year, but of course that's not the main

00:01:34: thing of that blog post.

00:01:35: Instead, in that blog post, where we

00:01:37: learn more about React's near future,

00:01:40: the main topic probably is the new

00:01:44: React compiler on which the React team

00:01:48: has been working for a while now.

00:01:50: Now, this React compiler is called

00:01:53: react-forget, and the idea behind this

00:01:56: compiler is that it will take a look at your

00:02:00: React code, essentially, and it will try to

00:02:04: do memoization for you.

00:02:07: Now, what does this mean?

00:02:09: Well, in React, as of today, without that

00:02:13: compiler, you sometimes have to use

00:02:16: the useMemo hook or the useCallback

00:02:19: hook or the memo function to wrap

00:02:23: logic or components to make sure that

00:02:26: they don't re-render unnecessarily,

00:02:29: because the way React works, it can

00:02:33: actually render components and

00:02:35: re-evaluate components unnecessarily

00:02:38: because it doesn't always understand if

00:02:42: a re-evaluation cycle is necessary or not,

00:02:46: and you therefore have to use these

00:02:48: hooks and so on to tell it that some value

00:02:51: didn't change in a certain component

00:02:53: and therefore no re-evaluation of that

00:02:57: component is needed, things like that.

00:03:00: Now, of course, we have all these tools in

00:03:02: React, though, so why do we need a

00:03:05: compiler and what is it really about,

00:03:07: what is memoization?

00:03:09: Well, we have to use these different

00:03:11: tools, useMemo, useCallback, and so on,

00:03:14: to tell React when to not render or

00:03:17: re-evaluate a component, and this

00:03:21: compiler, react-forget, is about doing

00:03:25: that for us so that we don't need to use

00:03:28: useMemo or useCallback or the memo

00:03:31: function anymore, but that instead, with

00:03:34: help of that compiler, React is able to

00:03:38: know and find out whether a

00:03:41: component really should be

00:03:43: re-evaluated or not, so that React gains a

00:03:47: deeper understanding of your code, you

00:03:49: could say, and therefore, with that

00:03:52: compiler, as a React developer, you

00:03:55: would have to worry less or maybe not

00:03:58: at all about making sure that

00:04:01: unnecessary re-evaluations are

00:04:04: prevented.

00:04:05: The React compiler would do that for

00:04:08: you in that future.

00:04:10: And that future is not too distant

00:04:12: because in that blog post, which the

00:04:15: React team shared, they also mentioned

00:04:18: that this React compiler is no longer a

00:04:21: research project, but that it instead

00:04:23: already powers Instagram.com in

00:04:26: production, so this compiler is already

00:04:29: being used on a large-scale project and

00:04:33: it seems to work quite well, otherwise

00:04:36: they wouldn't be announcing it here for

00:04:38: all React developers in the near future.

00:04:42: Now, it's also worth noting and

00:04:44: mentioned in this official blog post that

00:04:48: this compiler and the existence of that

00:04:50: compiler will not change the general

00:04:53: React mental model, where the UI is

00:04:57: essentially a function of your data and

00:05:02: your state.

00:05:02: That will not change, it's just meant to

00:05:06: decrease the complexity of the code you

00:05:11: have to write, or at least get rid of that

00:05:13: extra work you had to do regarding

00:05:16: those unnecessary render cycles that

00:05:19: needed to be prevented.

00:05:20: Which of course also was not just

00:05:22: annoying, but also a potential source for

00:05:25: bugs and problems, so it's great if we

00:05:28: get some help there.

00:05:29: Now, they also mentioned in that blog

00:05:31: post that in order for this compiler to

00:05:35: really work well, you must make sure

00:05:39: that the React code you write follows

00:05:43: certain rules or best practices, and

00:05:46: therefore the React team recommends

00:05:48: that if you want to make sure that you

00:05:52: follow React's rules, you enable strict

00:05:55: mode in your React projects and that

00:05:58: you use React's ESLint plugin, so that

00:06:03: you get early warnings if somewhere in

00:06:06: your code you have code that technically

00:06:09: works, but is not optimal, because that

00:06:13: code then might not be handled by the

00:06:16: compiler in the best possible way.

00:06:18: Though it's also worth mentioning that

00:06:21: the compiler, as it sounds from that blog

00:06:24: post at least, will work such that it

00:06:29: doesn't crash if somewhere in your code

00:06:32: you have code that can't be analyzed

00:06:35: and optimized automatically, it just

00:06:39: won't be able to do anything with that

00:06:41: code instead.

00:06:43: So it will skip compilation if it

00:06:45: determines that it isn't safe to compile

00:06:47: your code.

00:06:48: So that's that React compiler and it's a

00:06:50: really exciting initiative and project and I

00:06:54: can't wait to start using it and hopefully

00:06:57: get rid of a bunch of boilerplate code in

00:06:59: my codebase.

00:07:00: Now that compiler isn't everything that's

00:07:03: announced here though.

00:07:04: In addition we also get more details

00:07:06: about actions or server actions as most

00:07:11: developers might know them.

00:07:13: Though the blog post explicitly

00:07:16: mentions that what was previously

00:07:19: meant to be server actions, so a feature

00:07:24: that allows you to run code on the server

00:07:27: after a form is submitted, now actually

00:07:30: became actions that can be used either

00:07:33: on the server or also on the client, so

00:07:37: that this actions feature, which is about

00:07:39: to be added to React, will actually

00:07:42: simplify the process of handling form

00:07:46: submissions in React, even if it's just a

00:07:48: client-side React app without any

00:07:51: backend.

00:07:52: Now this is also interesting because this

00:07:54: actions feature is one of those features I

00:07:57: mentioned about which we mostly

00:07:59: heard in the context of Next.js, because

00:08:03: Next.js actually introduced stable server

00:08:06: actions with their latest version, Next.js

00:08:10: 14, and I do teach all about that in my

00:08:14: Next.js course for example, but it's

00:08:17: interesting to hear and see that it's now

00:08:21: the React team itself on their official

00:08:23: blog that's talking about this actions

00:08:26: feature and that this actions feature is a

00:08:29: feature that's not closely tied to Next.js

00:08:33: or frameworks in general, but that

00:08:36: instead every React developer will be

00:08:39: able to use it, at least that client-side

00:08:42: actions part.

00:08:43: The server-side part will always be a bit

00:08:45: more complex because naturally you will

00:08:48: need a backend for that and that's

00:08:51: exactly what a framework like Next.js or

00:08:54: Remix gives you, but for client-side

00:08:57: applications, single-page applications,

00:09:00: this client-side actions part could be

00:09:02: really interesting.

00:09:04: Now connected to those actions we also

00:09:06: get some new hooks which you can also

00:09:10: already use for example if you're using

00:09:13: Next.js because we're getting a

00:09:16: useFormStatus and a useFormState

00:09:19: hook which allow us to handle form

00:09:21: submissions and update the UI based on

00:09:23: them and so on, and a useOptimistic

00:09:26: hook which helps with optimistic UI

00:09:30: updates so that you can update the UI

00:09:33: the user sees even before the data has

00:09:36: been saved in a database, for example,

00:09:38: to give the user the best possible super

00:09:41: snappy user experience.

00:09:43: So that's another really interesting

00:09:46: feature and getting more help with form

00:09:50: submissions and of course getting that

00:09:53: tighter integration with the backend,

00:09:55: these are really exciting developments

00:09:58: which will allow React developers to

00:10:00: build even more amazing user

00:10:03: experiences with ease.

00:10:05: Now one problem React suffered from,

00:10:09: at least in my opinion, is that all these

00:10:13: new features like React server

00:10:15: components, for example, also were

00:10:18: developed and published on the canary

00:10:21: branch of React.

00:10:23: So not on the latest stable or main

00:10:25: branch but on a special branch or

00:10:28: channel I should say that could be used

00:10:32: by every React developer but not really

00:10:36: in an easy way I would say or at least this

00:10:40: canary branch was mainly intended to

00:10:43: be used by framework developers which

00:10:47: is why many of the features published

00:10:49: through that channel were available in

00:10:52: Next.js and were marked as stable there

00:10:56: even though they were not marked as

00:10:58: stable in React itself which was a bit

00:11:01: confusing at least for me and as far as I

00:11:05: can tell also for many other React

00:11:07: developers.

00:11:08: Now that will change as it seems with

00:11:11: the next major version or at least that

00:11:15: next major version React 19 which is

00:11:19: about to be released later in 2024 as it

00:11:22: seems that version seems to bundle a

00:11:26: lot of features that have all been stuck in

00:11:29: this canary channel for example the use

00:11:32: client and use server directives which

00:11:35: are needed for React server components

00:11:38: and also server actions so that is a huge

00:11:42: feature that's going to come to stable

00:11:45: React though it is of course worth

00:11:48: mentioning that if you plan on using

00:11:51: some server-side integrations some

00:11:53: back-end integrations you will still need

00:11:57: some framework that gives you that

00:11:59: integration because React itself is still a

00:12:03: library for rendering user interfaces in

00:12:06: the end it does not give you some

00:12:08: server-side integration out of the box

00:12:11: you will need to set that up on your own

00:12:14: or use such a framework nonetheless it's

00:12:18: nice to have it all in stable React itself in

00:12:22: the near future and we get some other

00:12:24: features I would guess that we get the

00:12:27: compiler though it's not explicitly

00:12:29: mentioned here in the blog post that it

00:12:32: will be included in the next major

00:12:34: version but I would guess that it is but

00:12:37: we'll for example also get access to some

00:12:39: new HTML elements that we can use in

00:12:43: our code HTML elements that will allow

00:12:47: us to easily set some head content of our

00:12:52: site so the title or meta tags for example

00:12:55: so that you don't need any third-party

00:12:58: packages for that anymore but it's built

00:13:00: into React instead we also get some new

00:13:03: features related to asset loading so that

00:13:06: React can help you with efficiently

00:13:08: loading fonts or CSS files and this will all

00:13:13: integrate with React's suspense feature

00:13:16: so that you can show some fallback

00:13:19: content whilst those assets are being

00:13:21: loaded so that can be useful we get

00:13:24: those actions which I already mentioned

00:13:26: they are part of that stable channel then

00:13:29: the client and server actions and it's also

00:13:34: really interesting that Andrew Clark

00:13:37: team member of the React team shared

00:13:40: a tweet or a post I guess on X where he

00:13:44: mentioned that by the end of 2024 we

00:13:47: will likely never need these APIs so these

00:13:51: React features again use memo use

00:13:54: callback and memo because of that

00:13:56: React compiler I mentioned forward ref

00:13:59: which I didn't mention yet because refs

00:14:02: will be accepted as standard props in

00:14:06: React components so if you build a

00:14:08: component that should accept the ref

00:14:10: you will no longer need to use forward

00:14:13: ref that seems to be another feature

00:14:15: that's coming with React 19 as it seems

00:14:18: React lazy should be made obsolete by

00:14:23: React server components and we'll also

00:14:26: get another new function the use

00:14:29: function I guess also with React 19 which

00:14:34: can be used to access context instead of

00:14:38: use context but which can also be used

00:14:41: to handle promises and build async

00:14:44: await like React components even if

00:14:48: you're not using React server

00:14:50: components because at the moment

00:14:52: with React 18 there indeed are async

00:14:56: components so components that can be

00:14:59: decorated with async await but we're

00:15:01: talking about server components here

00:15:03: so components that are rendered on the

00:15:05: server client only components on the

00:15:08: other hand can't use async await and

00:15:11: that's where this use function also

00:15:13: seems to come in the idea with that

00:15:15: essentially use also works a bit like await

00:15:19: and allows you to wait for a promise and

00:15:23: for the data that's produced by that

00:15:25: promise in client only components

00:15:28: which also is another nice feature and

00:15:31: therefore React 19 really is an upcoming

00:15:34: React version to be excited about and I

00:15:38: can't wait to see what we can build with

00:15:40: that version and of course it should go

00:15:43: without mentioning that I will keep my

00:15:46: React course updated as soon as there is

00:15:50: something to be updated and added

00:15:52: and that I will try my very best to give all

00:15:55: my students the best possible learning

00:15:58: experience in that course.