EXPLAINER

React

React is a JavaScript library for building user interfaces out of components that render when state changes. It is the usual UI layer in SPFx and in many AI chat panels, but it is not a backend or a complete framework.

Short answer: React builds UI as components in JavaScript or TypeScript. Next.js adds routing and server rendering. SPFx's default UI is React; see SharePoint Framework (SPFx). Chat-specific state is in Chatbot State and Conversation UI in React.

What it is

React is a library for building user interfaces, mostly in the browser. You write components, functions that return a description of UI (JSX, which looks like HTML inside JavaScript or TypeScript). When state changes, React renders again and updates the DOM to match. Props are inputs passed from a parent. Hooks such as useState and useEffect are how function components hold state and run side effects.

React is not a server, a router, or a data cache, though the ecosystem supplies those. Next.js is a framework on top. Building AI Interfaces with React and Chatbot State and Conversation UI in React cover AI chat UIs specifically. Does SPFx use React? The SharePoint generator's standard web part template does; details are in SharePoint Framework (SPFx). This page is React itself, including outside Microsoft 365.

Why and when it is used

Use React when the interface has a lot of state that should stay consistent with the screen: dashboards, editors, chat transcripts, admin tools. Components force you to say what the UI is for a given state, which scales better than jQuery edits scattered across a file. Use it because hiring and examples are plentiful, when that is true for your team.

Do not use React for a static document. HTML is enough. Do not use it on the server as your database. Do not adopt it, a state library, a CSS framework and a data library on the same afternoon. A component and useState carry a surprising distance.

How it works

You declare state. An event handler calls a setter. React schedules a render, calls your component functions, diffs the result against the previous tree, and updates the DOM. The "virtual DOM" is that diffing strategy, not something you manipulate. Effects run after paint and are for synchronising with the outside world (a subscription, a manual DOM call). Fetching in an effect is common and easy to get wrong (race conditions, missing dependencies).

Data should often live in a parent or a small store and flow down as props. A global store for every field is how apps become impossible to trace. Keys on lists must be stable ids, not array indexes, if items are inserted or removed. Strict mode in development renders twice on purpose to surface impure renders.

Technologies and dependencies

Node.js for the toolchain, React and React DOM packages, and a bundler (Vite is a sane default). JSX needs that toolchain. TypeScript is strongly recommended. Testing uses React Testing Library or a similar approach that clicks the UI rather than testing internal state. Next.js if you need routes and server rendering. SPFx if the host is SharePoint. None of these replace HTML and CSS.

How to get started

  1. Scaffold with Vite's React TypeScript template, or a blank project you understand. Resist a meta-framework until you have rendered a list.
  2. Build a component that shows a list of strings and a text field that appends one item. Lift state to the parent if a child needs to add.
  3. Open React devtools and watch state change when you click.
  4. Extract a child component that receives an item as a prop and does not own the list.
  5. Add one useEffect that subscribes to something and cleans up. If you have no subscription, you do not need an effect.
  6. Then look at Chatbot State and Conversation UI in React if the UI is a transcript, or at Next.js if you need URLs.

Keep components pure: the same props and state should describe the same UI. Side effects belong in event handlers and carefully written effects.

Cautions and trade-offs

Stale closures in async handlers show old state. Use functional updates or a ref when that bites. Over-fetching in effects causes waterfalls. Derived values do not belong in state if you can compute them during render. useEffect is not componentDidMount you sprinkle everywhere.

React's render model confuses people who expect to "grab the div and change it". When you do touch the DOM directly, you fight React. SPFx hosts React inside a page you do not fully control; do not assume document.body is yours. Finally, React will not structure your data. A single context with fifty unrelated fields is a ball of mud the library will re-render faithfully.