A session that goes under the hood of React itself. Most developers use React without ever knowing how it actually schedules and renders work. This changes that.
**
React Fiber** — A Complete Rewrite, Not Just an Update
React Fiber landed in React v16 and it wasn't a new feature — it was a ground-up rewrite of how React does its work internally. The old system had long-standing issues that couldn't be patched. Fiber fixed them properly.
The core idea: every component now has its own Fiber — also called a Unit of Work. What you see rendered on screen is called Finished Work. The Fiber is the behind-the-scenes representation, the Finished Work is what actually made it to the DOM.
The Old Problem — Stack Reconciler
The old reconciler used a Stack data structure. Stacks are synchronous by nature — last in, first out, and you can't stop in the middle. Once React started rendering a tree, it had to finish the whole thing before doing anything else.
Imagine a large component tree rendering and a user starts typing in a search bar. The old React would make them wait. The typing felt laggy because React was busy and couldn't pause. That's the problem Fiber was built to solve.
Fiber Reconciler — Async, Prioritised, Interruptible
Fiber replaced the Stack with its own Fiber data structure — a linked list of units of work that can be paused, resumed, reused, or thrown away entirely.
Here's what that unlocks:
Split work into chunks — every single component gets its own rendering unit. Not the whole tree at once.
Pause rendering — if React sees the user typing or clicking, it can pause low-priority work and handle the interaction first.
Reuse or abort work — if something changes mid-render, React can throw away what it was doing and start fresh with the new state.
Prioritise everything — work isn't equal anymore. React assigns priority levels:
Immediate — clicks, typing. Has to feel instant.
High — animations. Can't afford to drop frames.
Low — data fetching, background updates. Can wait.
If a low-priority fetch is happening and the user clicks something, React pauses the fetch work, handles the click, then comes back to the fetch. The user never feels the lag.
The Two Phases of Fiber
Phase 1 — Render Phase (Async)
This is where React figures out what needs to change. It runs beginWork() and completeWork() on each Fiber unit — building up a picture of the new UI in memory. This phase can be paused, restarted, or thrown away. Nothing has touched the real DOM yet.
Phase 2 — Commit Phase (Synchronous)
Once React has the full picture ready, it commits everything to the DOM in one go using commitWork(). This phase cannot be interrupted — it runs synchronously start to finish. The reason is simple: you can't have a half-updated DOM visible to the user. All or nothing.
react-quill — Rich Text Editing Without Building It Yourself
react-quill is a React wrapper around Quill.js — a powerful, modular text editor engine. Quill.js itself doesn't know React exists. react-quill just bridges the two worlds.
What you get is a fully functional WYSIWYG (What You See Is What You Get) editor — Bold, Italic, Underline, links, headings, lists — all the formatting tools a user would expect in a text editor, ready to drop into a React component.
import ReactQuill from 'react-quill';
Two lines and you have a production-ready rich text editor. Saves days of work.
Component Architecture — The Three Reasons It Matters
Everything in React is a component. But why that structure exists is worth understanding properly:
Reusability — write a once, use it across fifty pages. Change it in one place, it updates everywhere. This is the single biggest time saver in frontend development.
Isolation — components don't bleed into each other. If your breaks, you open SearchBar.js and the problem is right there. You're not hunting through thousands of lines of mixed code.
Composability — components nest inside each other naturally:
<NewsFeed>
<Post />
<Post />
<Post />
</NewsFeed>
doesn't need to know how renders. doesn't need to know it lives inside . Each one does its job. Together they build the whole UI. That separation is what makes large apps manageable.
Top comments (0)