import 'solid-js/h': SyntaxError: The requested module 'solid-js/web' does not provide an export named 'SVGElements'

[btakita]

Describe the bug

When importing from 'solid-js/h'

import h from 'solid-js/h'

The following error occurs:

file:///home/brian/project-path/node_modules/.pnpm/solid-js@1.5.1/node_modules/solid-js/h/dist/h.js:1
import { spread, assign, insert, createComponent, dynamicProperty, SVGElements } from 'solid-js/web';
                                                                   ^^^^^^^^^^^
SyntaxError: The requested module 'solid-js/web' does not provide an export named 'SVGElements'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:123:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:189:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:528:24)
    at async loadESM (node:internal/process/esm_loader:91:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)

Node.js v18.8.0

Your Example Website or App

https://stackblitz.com/edit/typescript-73v5pv?file=index.ts

Steps to Reproduce the Bug or Issue

import h from 'solid-js/h'

Expected behavior

The h function is returned.

Screenshots or Videos

No response

Platform

• Linux
• N/A
• 1.5.1

Additional context

No response

[ryansolid]

How unusual. I can see it being exported from the build.

[btakita]

I dont think solid-js/h has an ssr or nodjs implementation.

…

On Sun, Aug 28, 2022, 1:30 AM Ryan Carniato ***@***.***> wrote: How unusual. I can see it being exported from the build. — Reply to this email directly, view it on GitHub <#1187 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAA4UDQVS7V47B5ZNSHCFLV3MBQRANCNFSM572D5DEQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ryansolid]

It does not as it doesn't support those. We'd need different runtime for the h function which doesn't exist yet. Are you trying to run it SSR?

ryansolid/dom-expressions#148

[btakita]

I'm working on xml exports with namespaces on the server. I found that jsx does not support namespaces but h does. Currently, I'm using the xmlbuilder2 library.

[lxsmnsyc]

jsx should support namespaces normally

[btakita]

jsx should support namespaces normally

That's a pleasant surprise. Thank you.

A legit reason for supporting h is batch processing XML & HTML without having a build step or Vite.

[ryansolid]

What our h element generates is a bunch of DOM-specific code the way Solid works. So it requires a whole other runtime for a server h function. Not discounting it could be useful in some cases, but just haven't written it. Moreover I'm unclear if such an approach could be hydratable. That'd be a 3rd runtime.

[btakita]

With deno & bun supporting .tsx in the runtime, I would hope that nodejs would also support .tsx soon. Since .tsx supports namespaces, it should be sufficient for rendering xml for batch processing. I can already shoehorn solid-start/vite + curl for batch processing as well. So in that case h is not necessary.

[lxsmnsyc]

technically Node supports tsx and other extensions through the Loader API

[btakita]

Are there any examples of using node & the loader API to render solid components? I suppose it would be as simple as using renderToString with the loader api

[ryansolid]

With deno & bun supporting .tsx in the runtime, I would hope that nodejs would also support .tsx soon. Since .tsx supports namespaces, it should be sufficient for rendering xml for batch processing. I can already shoehorn solid-start/vite + curl for batch processing as well. So in that case h is not necessary.

Their support is mostly useless for us as far as I'm concerned. Standard transform is unoptimal and as I was detailing we'd need a bunch of runtimes for it. Ergonomics are poorer. Size and performance worse.

Using what we have means DOM emulation on the server which is why I'd be surprised if there were any examples of this.

[lxsmnsyc]

Are there any examples of using node & the loader API to render solid components

You can think of Node's Loader API as if Rollup was a runtime, which means you can intercept and transform requested modules before they are loaded by the importer module. The idea is fairly new but transforming TS files as well as compiling JSX should be possible with the Loader API

[btakita]

After discussing with both of you here & on Discord, it's evident to me that using tsx/jsx for xml output opens up a can of worms for marginal benefit. I'm going to stick with xmlbuilder2, especially since it has convert which can output xml to the builder object format. Thank you both for your time & attention.

[ryansolid]

I mean I can see it being a cool thing. But it probably would want its own JSX transform. Or like something like a custom renderer. Unless there is real benefit I'd go with tools that support this already because otherwise you are just building something new. Unless that's the intention.