Million.js

When using block(), the props object follows specific constraints regarding data types and interpolation:

1. Allowed Prop Values

props is an immutable object. It can contain:

• Primitive values (strings, numbers, booleans, etc.)
• Other Block instances

Invalid values:

• Plain objects (e.g., { imposter: true })
• Non-primitive objects like new Date()

2. Hole Interpolation Constraints

props are filled with immutable Hole objects (e.g., { $: 'prop' }). These are replaced with real values when the block(){:jsx} is called. Because of this, you cannot perform operations or destructuring on these holes.

Prohibited patterns:

• Destructuring: const { favorite } = props.favorite; is not allowed.
• String/Value Interpolation: props.foo + ' bar' is not allowed.
• Arithmetic/Method calls: props.count + 1 or props.foo.toString() are not allowed.
• Event Handlers: You cannot access a hole inside an event handler (e.g., onClick={() => console.log(props.world)}).

Allowed patterns:

• Direct usage in JSX attributes: <div className={props.className}>
• Direct usage in JSX children: {props.hello}
• Using non-hole values: {Date.now()}

// ✅ Allowed
block((props) => {
  return <div className={props.className}>
    {props.hello}
    {Date.now()}
  </div>;
});

// ❌ Prohibited
block((props) => {
  const { favorite } = props.favorite; // ❌ Destructuring
  return <div className={props.className + ' extra'}>
    {props.count + 1} {/* ❌ Arithmetic */}
    <button onClick={() => console.log(props.world)}> {/* ❌ Hole in event */} 
      Click
    </button>
  </div>;
});

The block() function is a Higher-Order Component (HOC) factory used to wrap React components for hyper-optimized rendering via Million.js.

When you wrap a component with block(), it creates a specialized 'block' that follows a specific lifecycle:

1. React Rendering: React renders a placeholder component (often called a Loader) which manages the initial lifecycle and state.
2. DOM Mounting: React mounts this placeholder and attaches a DOM element to a ref.
3. Million.js Rendering: Million.js takes control of that specific DOM element via the ref and renders the actual component logic using its own high-performance virtual DOM, bypassing React's reconciliation for that specific subtree.

This allows Million.js to manage a component's DOM independently of React, providing significant performance gains while still allowing the component to be used seamlessly within a React application.

function MyComponent() {
  // ...
}

const MyBlock = block(MyComponent);

export default function App() {
  return <MyBlock />;
}

Million.js is an optimization compiler that makes React components up to 70% faster by bypassing the standard React reconciliation process.

The Problem: React Reconciliation

In standard React, when state changes, React performs 'reconciliation' (diffing). It compares a new snapshot of the component tree against the previous one to identify what changed. This process becomes exponentially slower as the number of JSX elements increases, typically operating at $O(n^3)$ complexity.

The Solution: Direct DOM Updates

Million.js transforms reconciliation from $O(n^3)$ to $O(1)$ (constant time). Instead of performing a complex diffing operation across the entire tree, the Million.js compiler generates code that updates specific DOM nodes directly when their dependencies change. This allows components to run at near-native JavaScript speeds.

// Conceptual example of Million.js generated code
function App() {
  const [count, setCount] = useState(0);
  const increment = () => setCount(count + 1);

  // generated by the compiler
  if (count !== prevCount) {
    <p>.innerHTML = `Count: ${count}`;
  }

  <button>.onclick = increment;
}

In standard React, JSX is transpiled into React.createElement() calls, which produce JavaScript objects representing the Virtual DOM.

The Memory Problem

1. Object Storage: Every nested element in your JSX becomes a nested JavaScript object. A deep tree results in a massive, complex object structure stored in memory.
2. Diffing Overhead: When state changes, React must compare the entire old Virtual DOM tree with the new one to determine what changed in the real DOM. This is a CPU-intensive operation.
3. Garbage Collection (GC) Pressure: Every time a component re-renders, old Virtual DOM objects are discarded and replaced with new ones. This constant cycle of allocation and deallocation forces the browser's Garbage Collector to run frequently. Since GC is a blocking operation, frequent or large-scale collections can introduce noticeable delays (jank) in the UI.

Best Practices for Standard React

To mitigate these issues in plain React, it is recommended to move useState() and useEffect() as far down the component tree as possible. Smaller components mean smaller diffing processes and less work for the engine when a specific part of the UI updates.

// Standard React element representation (simplified)
{
    $$typeof: Symbol(react.element),
    key: null,
    props: { children: "Hello world" },
    ref: null,
    type: "div"
}