An unofficial show note for React Today and Tomorrow with the React Core Team
react, podcast, shownote
react, podcast, shownote
Just listened to React podcast episode 27: React Today and Tomorrow with the React Core Team.
So much content was covered regarding new React features and "why"s behind it.
Below is the "unofficial" show notes highlighting the discussion.
The purpose is to enable code splitting and it's baked into React to promote an easier use and adoption.
The alternative is that people would forget to split code and bundle everything in one file.
Adding it into React makes it easy to use it and can be optimized better than user land option such as React Loadable.
Fix all warnings using React Strict Mode before opting in.
Andrew Clark plans to write a "thorough" documentation on it.
The purpose is to solve a priority queue coordination issue (mentioned below) in a browser thus it's not tied to React and is a general library.
The issue is that different libraries in a website has a different priority and to solve it, Scheduler coordinate the task/events in a browser level.
e.g.) React has its own priority queue scheduling system. When dealing with other parts of the browser, which has its own scheduling system, which one takes priority?
Scheduler aims to solve that coordination problem.
React team is working with Chrome team to standardize scheduling.
Scheduler usually be abstracted from a developer as it will usually be available in framework level.
Rarely will there be a reason to use it directly.
Dan advised to avoid "high" and "low" for priorities but to use "normal" for priority.
When a priority task needs to be blocked (user input), prefer the term "interrupting priority" instead of "high priority" task.
Sung's side note: Funny as the word "priority" implies "importance" already. that we use "high" & "low" to refer to priorities.
_React team deprecated _componentWillMount_ as Michael Jackson has been abusing it (Refer to Sohpie's response @ __25:05 _😂 j/k.
Serves two purposes
A browser devtool for profiling duration of React component commit to the DOM.
You can still see the wall time (elapsed real time) but it's more about duration spent on a component.
The profiler aims to provide an easier view on component's commit time.
Basing the profiler on "commit" helps you focus on performance of React components you created, not that of React core or the browser.
Profiler in action
It enables you to progmatically gather profiler data.
If you want to know more about profiling, refer to the React documentation.
It's hard to share non-render logic (embedded in life cycle methods) between components.
Hooks provide a way to simply extract by copy/cut & paste non-render logic into smaller chunks and share them across function components.
Using hooks results in a simpler API & smaller/readable code base.
There is a plan to create practical how-tos inspired by React Router documentation.
Sung's side note:_ Error Boundaries type of documentation will be nice since everyone just copy/paste the reference implementation._
Can't be used inside conditionals.
Think about this. You don't declare/define states or life cycle methods conditionally.
As hooks mirror those features, it doesn't make sense to use hooks within a condition.
Prefix with "use".
Order in which hook is defined matters
e.g.) render should be a pure method enabling React to take advantage of it.
e.g.) When you deal with code that requires subscribing in cDM and unsubscribe in cWU, it can causes a leak or a buggy code.
If your code requires an ID to un/subscribe, you need to consider the case where the ID is updated between cDM & cWU, which you need to check within cDU.
useEffect is called every time during an update to prevent such error.
You can further optimize it using the 2nd argument of useEffect to make it run only when the specified list of property is updated.
Hooks looks hard but easy to use while current React looks easy but hard to use.
This is an "unofficial" show note of React podcast episode 27: React Today and Tomorrow with the React Core Team as I am not affiliated with the podcast in any way.
I've tried to compile the show note as grouped as possible while writing notes on a piece of paper.
If you liked the show note, would you let me know should you find anything missing, wrong, or require an update?
Lastly subscribe to React podcast, and follow React core team on twitter (which you can find in the official React podcast show note) as they are very active on it.