feat(jsx/server): introduce jsx/dom/server module for compatibility with react-dom/server

[usualoma]

Implement React compatible renderToString and renderToReadableStream.
This component is used to create an alias in #2925

Is the name jsx/dom/server appropriate?

As it is a component that provides stringify function, I don't think it is related to “DOM", but I chose this name because it is easier to understand if it corresponds to "react-dom/server".

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.45%. Comparing base (fe7cfcf) to head (147223f).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2930      +/-   ##
==========================================
+ Coverage   94.42%   94.45%   +0.03%     
==========================================
  Files         136      137       +1     
  Lines       13343    13424      +81     
  Branches     2219     2236      +17     
==========================================
+ Hits        12599    12680      +81     
  Misses        744      744              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[usualoma]

@yusukebe Would you please review?

[yusukebe]

Hi @usualoma !

I don't know if it will be the best way but have you ever thought about implementing renderToString and renderToReadableStream in @hono/react-compat? I think if these are used only for that module, it will be a good idea. Though if jsx/dom/server will be used in other places e.g. vite.config.ts, we have to implement this in hono package.

[usualoma]

@yusukebe Thanks for your comment!

In my opinion, the best way to do this is to "not include any implementation in @hono/react-compat". The only code included is re-export in “@hono/react-compat".

export * from 'hono/jsx'.

But I also see your point. You mean that this PR code is "just a wrapper for React compatibility, it doesn't add any new value", so does it really need to be added to "hono"?

It could be used in "vite.config.ts" or "honox", but, well, I don't have any concrete ideas at the moment.

I know there are different opinions, but I would prefer this code to be in "hono" instead of "@hono/react-compat".

[usualoma]

Oh, just to say, "@hono/react-compat" is currently aliased to "hono/jsx", but if it is aliased to "hono/jsx/dom" and aimed at something "client-side only, but very very small", it is possible that this pull request's implementation is not needed in the first place.

[yusukebe]

Hi @usualoma

You mean that this PR code is "just a wrapper for React compatibility, it doesn't add any new value", so does it really need to be added to "honor"?

Yeah, definitely. But it's okay to merge this PR! It was not a big problem for me. With this PR, the code in @hono/react-compat will be minimal, and jsx/dom/server may be used in other places.

[yusukebe]

Can you update jsr.json too?

[usualoma]

@yusukebe
Thank you.
I updated jsr.json in 3f2dcfc.

[yusukebe]

LGTM!

[yusukebe]

@usualoma Thanks!

I'll leave this not merging because this is a feat. But, I may include this change in a patch version since this is not a big feature for end-users.