# Thoughts The fact that React is efficient is still baffling to me. Virtual DOM feels so "wasteful". So many trees of virtual DOMs are being generated; however, this must all be worth it. (Actually, after learning about how reach figures out what to render; this feels less wasteful) I remember being both impressed by Angular 1.x and [[FE Framework History#Knockout.js|knockoutjs]] (Knockout.js was especially magical, as it required a very careful wiring of the application to work correctly) I actually really like the fact that React is lightweight. In the [[Framework-Library spectrum]], React is definitely a framework. However (as you want to do things "the react way" and want to share "react components"). However, other than the fact that React provides the building blocks, it imposes very little opinion on how one should structure the application. Concepts such as *router* are not present in the framework core. Even Redux is not part of React itself. # Component, Instance, Elements `Elements = What JSX tags compile to` This is one of the clever thing about JSX. It’s a language extension and language extensions come with their own caveats; however, keeping it as syntax oriented as possible was a good architecture decision. * JSX is optional * It forces the upper limit on “magic” as it's purely declarative (plus a function call at the end). * This allows for alternate implementations; ie: React Native. In fact, one can imagine a use case for this without any React! REFs - https://reactjs.org/docs/refs-and-the-dom.html ## "Headless" UI React popularized the concept of the *headless* UI components; like https://headlessui.com/, or https://www.radix-ui.com/primitives. - Provides un-styled UI elements; - React components with behaviors. - It's your job to style them in whatever way you want. - Benefit: can fit in *any* frontend framework, as long as you're using react. - in some sense, these are meta-frameworks, allowing libraries like [[shadcn]] to exist as a wrapper on top of it. - Before, [[CSS]] classes had to be the interface between the components and styling; however, this forces a lot of limitations. - css classes are defined by the component, which may follow their own conventions. - no good understanding of the DOM structuring (which css styling necessarily needs). - to a certain degree [[CSS]], especially via classes, creates tech debt and eventually becomes a spaghetti code. perhaps [[tailwindcss]] is right all along; that css classes (that are not utility classes) should be shunned upon. The headless uI is slightly tricky to use as nothing prevents you from nesting the DOM wrong; you need to look at a documentation like: ```tsx export default () => ( <Dialog.Root> <Dialog.Trigger /> <Dialog.Portal> <Dialog.Overlay /> <Dialog.Content> <Dialog.Title /> <Dialog.Description /> <Dialog.Close /> </Dialog.Content> </Dialog.Portal> </Dialog.Root> ); ``` (from https://www.radix-ui.com/primitives/docs/components/dialog) and figure out what's going on. # Internals ## [[React Hooks]] Hooks allow the functional component (effectively all new React code) to have side effects. ## React.Component - aka Class Components *Functional components* versus *class components;* https://www.robinwieruch.de/react-class-component-deprecated/ https://www.robinwieruch.de/react-hooks/ https://reacttraining.com/blog/where-did-hooks-come-from - this shows a good history of React. https://beta.reactjs.org/learn/state-a-components-memory ## React Compiler `useMemo` and `useCallback` needs to be used extensively to make application more efficient. The idea is, can these be programmatically be applied? "Rules of React" should really be its own programming language; `eslint` really helps at addressing this, but it is still error prone. ## Advanced Function Component These are not necessary for normal react programming, but is useful if you are creating a library like [[radix-ui]]. - `asChild` - https://www.radix-ui.com/primitives/docs/guides/composition - "spreading the prop" - `const MyButton = (props) => <button {...props} />;` - `React.forwardRef` - https://react.dev/reference/react/forwardRef, or the `ref` prop starting from React 19. ## Dependence on Javascript's equality behavior React doesn't re-render if the passed in props don't change. This is checked via the js equality operator with no custom behavior. The hooks `useCallback` and `useMemo` needs to be used to ensure that the re-render are effective / no render loop occurs. This is where [[#React Compiler]] (if introduced) will help, as it would eliminate the manual useCallback / useMemo optimization. ## Promises, `use()`, and `Suspense` - `use()` resolves either contexts or promises. - for contexts, it is similar to `useContext()`, except it doesn't need to follows the [[React Hooks]] rules, and can exist under a conditional. - Q: I wonder if other hooks can be retrofitted to support this also. - `use()` on promises add new capabilities; it allows for partial rendering of components. - `use(p)` either resolves the promise, or throws an exception. - this error propagates the component tree under a `<Suspense/>` element is reached. - # Client versus Server This is a bit tricky, as it's hard to figure out what is provided by React versus frameworks (like [[NextJS]]). **client components** - the traditional react code. **server components** - runs on server; this allows us to mix backend API calls (say database retrieval) with the rendering logic. - this reminds me of the traditional web programming (JSP, etc), except we can use jsx/tsx files. - can be `async` (client components cannot be async, though `use` can pass server promise into client components) - need framework support ## Server-Side Rendering (SSR) - Annoyance - Date Rendering. This is a common source of ## Static Site Generation (SSG) > [!warning] is this still hot? [[NextJS|nextjs]] [[Remix]] [[NextJS|gatsby]] 🪦 ## Server Functions https://react.dev/reference/rsc/server-functions this allows client components components to call directly into server code. i.e. `onClick` handlers can call server code without any additional scaffolding. - the fact that this is doing a remote call (fetch or xhr) is fully hidden. - json serialization, typesafe. > [!thought] > Hard to figure out what is provided by React versus [[NextJS]]. This is especially true *before* React 19, where NextJS had access to React 19 features before any other frameworks. # By Releases ## React 16.8 - Hooks ## React 18 - Introduced [[#Server-Side Rendering (SSR)]]. - This broke a lot of [[CSS|CSS-in-JS]] ## React 19 - Server Components (Asynchronous components) - [[Server Actions]] - `use()` ## React 20 - React Compiler