Behind the block()

If you've used Million.js for a while, you've probably heard of the block() function.

function MyComponent() {
  // ...
}
 
const MyBlock = block(MyComponent);
 
export default function App() {
  return <MyBlock />; // ✨ it works! ✨
}

Wrapping a React component with block() creates a block. A block is a special Higher Order Component (HOC) (opens in a new tab) that can be used as a React component but are hyper-optimized for rendering speed by rendering using Million.js.

But how can this be? How can we use blocks inside of React? Isn't Million.js a completely different virtual DOM?

Anatomy of block()

Once you've created a block and use it as a React component, the following will occur during rendering:

This pattern allows us to "control" the DOM element without React knowing about it. React will only know about the <Loader /> component, and Million.js will only know about the <App /> component.

Implementing block()

With this in mind, we can create a basic implementation of this pattern.

const block = (ReactComponent) => {
  return function Loader(props) {
    return /*... */;
  };
};

const block = (ReactComponent) => {
  return function Loader(props) {
    const el = useRef(); // stores the DOM element
 
    return <div ref={el}></div>;
  };
};

const block = (ReactComponent) => {
  const MillionComponent = Million.convert(ReactComponent);
  return function Loader(props) {
    const el = useRef();
 
    // 3. Million.js renders <App /> into the ref
    const effect = useCallback(() => {
      // useCallback is used as a stable closure reference
      Million.render(MillionComponent, el.current);
    }, []);
 
    // 2. React mounts <Loader /> and puts the DOM element in the ref
    return (
      <>
        <div ref={el}></div>
        <Effect effect={effect} />
      </>
    );
  };
};
 
// Effect is a component that runs an effect on mount
function Effect({ effect }) {
  useEffect(effect, []);
  return null;
}

Compiler, you're a wizard! 🧙

One major limitation of the runtime implementation is that it requires the user to pass in a stateless component. This is because the internal block implementation has a number of limitations. However, we can use the compiler to get around this limitation.

Let's say we have an <Emotion /> component that has some isSad state, and based on that state, it renders a 😢 or 😂 emoji.

function Emotion() {
  const [isSad, setIsSad] = useState(true);
  return <div>{isSad ? '😢' : '😂'}</div>;
}
 
const EmotionBlock = block(Emotion);

The compiler can extract out the isSad state and convert it into a prop that Million.js can understand.

function Emotion_jsx({ _0 }) {
  return <div>{_0}</div>;
}
 
const Emotion_jsx_block = block(Emotion_component);
 
function EmotionBlock() {
  const [isSad, setIsSad] = useState(true);
  return <Emotion_jsx_block _0={isSad ? '😢' : '😂'} />;
}

But what if we had another React component inside of <Emotion />?

function SadEmoji() {
  return '😢';
}
 
function HappyEmoji() {
  return '😂';
}
 
function Emotion() {
  const [isSad, setIsSad] = useState(true);
  return <div>{isSad ? <SadEmoji /> : <HappyEmoji />}</div>;
}
 
const EmotionBlock = block(Emotion);

Similarly, this is extracted, but during rendering when it meets a component boundary, it will create a "React render scope." Essentially, it delegates the responsibility of rendering the component to React.

function SadEmoji() {
  return '😢';
}
 
function HappyEmoji() {
  return '😂';
}
 
function Emotion_jsx({ _0 }) {
  return <div>{_0}</div>;
}
 
const Emotion_jsx_block = block(Emotion_component);
 
function EmotionBlock() {
  const [isSad, setIsSad] = useState(true);
  return (
    <Emotion_jsx_block
      _0={renderReactScope(isSad ? <SadEmoji /> : <HappyEmoji />)}
    />
  );
}

As you can see, the compiler is able to extract out the state and render it from a parent element. It can also recognize when it hits a component boundary and delegate the responsibility of rendering to React.

Not just Million.js

While this article details how Million.js takes advantage of this pattern, it is not limited to just Million.js.

For any modern framework that can render into a DOM element, you can use the <Loader /> and HOC pattern to render foreign framework components inside of React.

A very similar concept is the "islands architecture" (opens in a new tab), which allows you to incapsulate any framework into static HTML. This is a bit different, instead of rendering into static HTML, it renders into a React tree.

Why not a compatibility layer?

JavaScript frameworks like Preact (opens in a new tab) and Inferno (opens in a new tab) have compatibility layers that allow them to masquerade as React components but with better performance. This has a lot of benefit, as it allows projects and engineering teams to move very fast without having to rewrite their entire codebase.

But it comes at a cost. Compatibility layers always have to play catch up. When React adds a new feature, the compatibility layer has to add support for it. Maintaining the same behavior is near impossible, especially emulating the same behavior and benefits of the React concurrency model.

Closing Thoughts

By using specific different rendering methodologies on a component-by-component basis, we can take advantage of the best of both worlds and use the right tool for the right job. Hopefully one day, we'll see more frameworks adopt this pattern. Because performance shouldn't be a tradeoff for migration.

Discuss on Twitter (opens in a new tab) | Edit on GitHub (opens in a new tab)

Acknowledgements

Thank you to Ryan Carniato (opens in a new tab) for creating an initial Solid.js inside React proof-of-concept (opens in a new tab) that inspired this article.

Looking for more? Check out another interesting read (opens in a new tab) from Yongjun Park (opens in a new tab).