React Podcast Show Notes (3 Part Series)
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.
- Only supports an immediate fallback in this version.
- v16.7 will enable pausing before showing.
- Server Side Rendering (SSR) is not yet supported.
Fix all warnings using React Strict Mode before opting in.
Andrew Clark plans to write a “thorough” documentation on it.
- You will be able to test just like a synchronous code
- React team plans to provide a helper method to enable specific current mode testing in libraries/frameworks.
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.
- Certain events will still occur synchronously due to legacy browser APIs such as text and keyboard inputs as they tab into OS level API.
- Predictable events such as tabbing & clicking will occur serially.
- while an event like mouse will be batched into a low priority queue.
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
- People can try out Suspense in v16.7 after an initially release until vendors like Relay or Apollo libraries can implement a cache using this reference implementation.
- For one-off scenarios like caching images, or other media files where you don’t need a full blown cache provider.
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.
- Shows name of components “you” created making it easy to scan.
- Amount of time spent in milliseconds to render a component.
- Colors to indicate performance issues.
- Gray : not rendered (e.g. PureComponent or shouldComponentUpdate() set to false).
- Cool blue : Fast commit.
Bright yellow : Slow commit.
- Use your judgement whether to optimize the slow performance as the color shows relative difference (it could be 5ms or 300ms depending on the situation or users systems, fast/slow laptops).
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
- Same way you’d write your synchronous code.
- Can use the logic multiple times (shareable).
- Enables easier logic composition.
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.
The post An unofficial show note for React Today and Tomorrow with the React Core Team appeared first on Sung's Technical Blog.