react-fiber-architecture VS JSS

Here is great documentation for you to follow if you are interested in understanding the core concepts.

Can someone remind me why virtual DOM was/is desirable in the first place and why updating the DOM directly is desirable now?

If I understand correctly react elements are created in memory, and only upon "render" it is turned into the actual DOM. Supposedly manipulating the actual DOM is "heavy" hence delay/pruning the virtual DOM tree first then rendering would be beneficial? Then why is it working with DOM directly is desirable? And am I right to assume that "without virtual DOM" means work with DOM directly? Someone in the comment mention that Svelte is without vDOM already. Is there some design document that I can refer to, like the reconciliation engine used in react https://github.com/acdlite/react-fiber-architecture

Перевод статьи Эндрю Кларка “React Fiber Architecture” https://github.com/acdlite/react-fiber-architecture

Over the years, new view libraries that are even more performant than React have emerged. React may not be the fastest library out there, but in terms of the ecosystem, overall usage experience and benefits, it is still one of the greatest. Facebook is also channeling efforts into making React even faster with a rewrite of the underlying reconciliation algorithm. The concepts that React introduced has taught us how to write better code, more maintainable web apps and made us better engineers. We like that.

The concept is a bit complex, but if you're interested in finding out how we might see React in a few years, you can read this documentation from the React page: https://github.com/acdlite/react-fiber-architecture

Fiber is the new reconciliation engine in React 16. Its main goal is to enable incremental rendering of the virtual DOM. This is a complicated concept, basically, this new algorithm is a reimplementation of older versions of the React reconciler, has some improvements on prioritizing the order of how things are rendered, breaks the limits of the call stack, and lets it pause or start rendering work wherever required. You can read more here and here

The result was "Jikji" library (why Jikji? it will need another blog:)) ). It uses React Fiber to get the component hierarchy and reorganized, split, and layout the components before rendering and making a print-ready web view that can easily be printed or converted to PDF or images.

The mechanism to diff one tree with another to determine which parts need to be changed and then update the original DOM with it is called Reconciliation. You can learn about Reconciliation here. ReactJS uses a new reconciliation engine called Fiber since version 16.0. You can read more about the React Fiber Architecture here.

Most websites those days are SPA applications that render on the front-side. There is also this trend of CSS in JavaScript also knowns as JSS that is debatable (makes everything overcomplicated), but in some specific cases, can be justified and very useful.

> why tf aren't we using JS for styling already

People are and have been for quite a while

https://cssinjs.org/

JSS

It is possible. At its most simple, you could just modify the style property on every element. That's not generally considered best practice, but there are a number of "CSS-in-JS" libraries which streamline the process. The typically generate dynamic CSS classes and apply them to your elements. A big one is JSS.

import React, { useState, useEffect } from "react"; import Amplify, { API, graphqlOperation } from "aws-amplify"; import { createBlog } from "./graphql/mutations"; import { listBlogs } from "./graphql/queries"; import awsExports from "./aws-exports"; import { ListBlogsQuery } from "./API"; Amplify.configure(awsExports); const initialState = { name: "", body: "" }; const App = () => { const [formState, setFormState] = useState(initialState); const [blogs, setBlogs] = useState(); useEffect(() => { fetchBlogs() }, []); const handleInputChange = (event: React.ChangeEvent) => { setFormState({ ...formState, [event.target.name]: event.target.value }); }; const fetchBlogs = async () => { try { const blogData = (await API.graphql(graphqlOperation(listBlogs))) as { data: ListBlogsQuery } setBlogs(blogData.data); } catch (err) { console.log("Error fetching blogs" + err); } }; const addBlog = async () => { try { if (!formState.name || !formState.body) return; const blog = { ...formState }; if (blogs) { await API.graphql(graphqlOperation(createBlog, { input: blog })); await fetchBlogs(); setFormState(initialState); } } catch (err) { console.log("error creating blog: ", err); } }; return (

Amplify Todos

Create Blog {blogs && blogs?.listBlogs?.items?.map((blog, index) => { return (

{blog?.name}

{blog?.body}

); })}

); }; const styles = { container: { width: 400, margin: "0 auto", display: "flex", //real weird issue: https://github.com/cssinjs/jss/issues/1344 flexDirection: "column" as "column", justifyContent: "center", padding: 20, }, todo: { marginBottom: 15 }, input: { border: "none", backgroundColor: "#ddd", marginBottom: 10, padding: 8, fontSize: 18, }, todoName: { fontSize: 20, fontWeight: "bold" }, todoDescription: { marginBottom: 0 }, button: { backgroundColor: "black", color: "white", outline: "none", fontSize: 18, padding: "12px 0px", }, }; export default App;

Material UI v5 brought some amazing updates, but switching from JSS to Emotion had an arguably nasty side-effect: it was no longer as straightforward to group your component styles in classes. Fortunately, a fantastic library emerged that allowed developers to not only reduce the extreme pain from migrating all their classes from v4's makeStyles to emotion, but to also to continue to writing classes in practically the same syntax, with wonderful TS type-safety. This library was tss-react, and it was one of my favorite open source discoveries of 2021.

I started writing a long response, but I want to add that a simple CRA + JSS + TS (named exports only) stack solves or abstracts away most of these issues.

JSS