feat(jsx/dom): rewrite renderer to use virtual tree

[usualoma]

By #1917 and #1955 we found that we could achieve "render to dom" with our own implementation and it made sense, but it was, to put it mildly, a rather dirty implementation and an impossible one to maintain.

As mentioned on #1909 (comment), I think the cost of implementation is high, but still, without a virtual tree approach, the code for this feature is I don't think it would be maintainable.

So, I would like to replace it with this implementation that creates a virtual tree.

Differences from #1917, #1955

Async component is not supported

Unfortunately, as with the original React, it is not possible to use async components when rendering to dom. I was very worried about this, but I still think it would be better not to support this because it would not be possible to match the policy for rendering JSX to DOM.

const Component = async () => {
  const num = await promise
  return <div>{num}</div>;
};

use hook is available and should be used when rendering to dom.

const Component = () => {
  const num = use(promise)
  return <div>{num}</div>;
};

Small

"src/jsx/dom/render.ts" is very small, about 3 Kb.

$ npx esbuild --minify src/jsx/dom/render.ts | wc
       1      66    3132

Author should do the followings, if applicable

• Add tests
• Run tests
• yarn denoify to generate files for Deno

[usualoma]

This PR also fixes these issues.

Fixes #1944
Fixes #1941
Fixes #1942
Fixes #1943

[yusukebe]

@usualoma

It's amazingly small! It is good that the implementation is small and easy to maintain. It's good if working AsyncComponent with use.

What I am concerned about is the case where the server and the client see the same component. This is an important issue for Islands Architecture, which will be introduced in v4.

I tried this PR code, but, of course, the use did not work on the server. The code is below.

import { useState, use } from 'hono/jsx/hooks'

export default function Counter() {
  const promise = new Promise((resolve) => setTimeout(resolve, 2000))
  use(promise)
  const [count, setCount] = useState(0)
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

Repo: https://github.com/yusukebe/hono-jsx-front-poc/tree/dom

What we need to consider is the use specification. If we use use on the server side as well, should it wait until Promise resolves it or not? If we follow the client's spec, it should wait. But, for example, it might be a good UI if the server does not wait for use to resolve, but returns HTML and waits at the client.

What do you think about the server and client referring to the same component regardless of use?

[usualoma]

Behavior of use() in React

render() to DOM

This code does not work

export default function Counter() {
  const promise = new Promise((resolve) => setTimeout(resolve, 2000))
  use(promise)
  const [count, setCount] = useState(0)
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

We need to pass the same object to use().

const promise = new Promise((resolve) => setTimeout(resolve, 2000)) // Define outside the component or cache it somewhere

export default function Counter() {
  use(promise)
  const [count, setCount] = useState(0)
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

renderToString()

renderToString() does not support Suspense

renderToReadableStream()

This code works.

export default function Counter() {
  const promise = new Promise((resolve) => setTimeout(resolve, 2000))
  use(promise)
  const [count, setCount] = useState(0)
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

Behavior of use() in hono/jsx

render() to DOM

As with React, the former code will not work. The latter code works.

toString()

at caba00e, the former code will not work. The latter code works. I believe you saw this and commented.

at f7070ae, also the former code works like React's renderToReadableStream()

Conclusion

If the result should be the same whether rendering to DOM or toString(), then the code in caba00e is sufficient and f7070ae is unnecessary.
However, I think that f7070ae is also useful, so I think it is OK to include it.

[usualoma]

@yusukebe
If you do not see a problem, you may have this PR merged.
This PR is still not that small because bundling always introduces unnecessary code for toString(), but #1986 will allow bundling of only the dom render, which is expected to make it very small.

[yusukebe]

@usualoma

Thanks!

I am wondering if the counter sample in the following repository will work or not. From what I have tried, it does not work with the latest code from this PR. I think this should work, am I wrong? I would be glad if you could check.

https://github.com/yusukebe/hono-jsx-front-poc/tree/dom

[usualoma]

@yusukebe
OK, use() should be used in Suspense.

import { Suspense } from 'hono/jsx'
import { useState, use } from 'hono/jsx/hooks'

const promise = new Promise((resolve) => setTimeout(resolve, 2000))

function Counter() {
  use(promise)
  const [count, setCount] = useState(0)
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

export default function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Counter />
    </Suspense>
  )
}

[yusukebe]

@usualoma

Thanks! I would like to do the following.

• Server and client use the same AsyncComponent.
• The server returns AsyncComopent without waiting. In this case, it returns the contents of the Suspense fallback.
• Client displays the contents of the fallback until the Promise is resolved, then displays it resolved.

In the following code, the application waits 2 seconds on the server side for the first access and then waits 2 seconds on the client. On the second and after, the app waits 2 seconds on the client only.

What I'm expecting is this "behavior after the second time". This means that the client only waits 2 seconds, and the server does not wait - In actuality, my ideal is - the server returns the contents of the fallback, and the client also initially renders the fallback (as hydration) and then shows the contents from the client after 2 seconds.

// component.tsx
import { use } from 'hono/jsx/hooks'

const promise = new Promise((resolve) => setTimeout(resolve, 2000))

export default function Component() {
  use(promise)
  return <p>Done!</p>
}

// server.tsx
app.get('/', (c) => {
  return c.render(
    <div id="target">
      <Suspense fallback={'on server...'}>
        <Component />
      </Suspense>
    </div>
  )
})

// client.tsx
document.addEventListener('DOMContentLoaded', function () {
  const target = document.getElementById('target')
  render(
    <Suspense fallback={'on client...'}>
      <Component />
    </Suspense>,
    target
  )
})

Area.mp4

This behavior is expected according to the specification. Therefore, it may not be necessary to change it. However, I cannot realize what I want to do. What do you think about this matter? Or do I expect the wrong things? I'm sorry to bother you.

[yusukebe]

Or it may be better to separate the roles of the server and client components as follows:

• Handling AsyncComponent with Suspense - e.g. fetch external resources => Server Components
• Build a UI with interactions => Client Components

A quick search shows that Next.js has a similar approach.

[yusukebe]

@usualoma

I'm sorry. Please ignore what I have written above!

It is a very rare case that this server and client reference the same AsynComponent and SSR that hydrates it. I think it is not used very often (especially in the file-based routing framework we are trying to create) and should not be recommended.

I will merge if you are OK!

[usualoma]

@yusukebe
Thanks for checking!
Let's follow up on any improvements that need to be made. As for this PR, I am fine to have this merged.

[yusukebe]

Yeah! I'll merge this now.