You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My goal is actually to replace all instances of DOM types (including HTMLElement etc) with my own custom type provided by a universal renderer, but this minimal repro establishes what the problem with that is.
The divide between 'solid-js' and 'solid-js/web' gives the impression that all web-related code is sectioned off into the web renderer, but that's only true at runtime, and not to typescript. The core JSX type is web-specific, and part of solid-js. it gets used in a few places, including the type definition of things like the Component<> type and the control flow primitives.
Because the runtime implementation is still doing the right thing, this can be worked around by allowing the dom types and then overriding them wherever you need to use them, but this comes at the cost of extensibility (can't make a solid-js library without depending on the web types) and maintainability.
Remove 'dom' from your global type definitions. (in the repo that is done by "lib: ['ESNext']" in the tsconfig
pnpm build
observe build errors. examples:
node_modules/.pnpm/[email protected]/node_modules/solid-js/types/jsx.d.ts(9,19): error TS2304: Cannot find name 'Element'.
node_modules/.pnpm/[email protected]/node_modules/solid-js/types/render/hydration.d.ts(12,28): error TS2304: Cannot find name 'Element'.
Expected behavior
It should be possible to use the core reactive library without depending on the dom. likewise, it should be possible to use an entirely separate universal renderer without pulling in the dom types.
Screenshots or Videos
No response
Platform
all
Additional context
This is a larger task. It may require backwards-incompatible changes, and it would need input from core maintainers. I have some thoughts on how to approach this, I'll leave them in a follow-up comment
The text was updated successfully, but these errors were encountered:
Any time the word JSX is used, that would need to be moved into the web folder, transitively. so that'd include the control flow components and core types, and so on. non-web users are left to fend for themselves. (you kind of have to do this anyways for a complete implementation: so far I've re-implemented and and I'm sure there's others)
Approach 2. Replace all instances of JSX types with generics
This would need a proof-of-concept before I could say this is actually possible, generics can be confusing! and this would likely reduce the readability of error messages for the vast majority of users. I would combine it with approach 1, where the variants exported by the web package are always the concrete types, for ergonomics reasons.
Approach 3. Return all dependent runtime functions from the createRenderer call
This has the benefit of only needing one generic, at the initial createRenderer method. but implies runtime changes that the other solutions would not.
Describe the bug
This is a continuation of:
ryansolid/dom-expressions#277 (comment)
My goal is actually to replace all instances of DOM types (including HTMLElement etc) with my own custom type provided by a universal renderer, but this minimal repro establishes what the problem with that is.
The divide between 'solid-js' and 'solid-js/web' gives the impression that all web-related code is sectioned off into the web renderer, but that's only true at runtime, and not to typescript. The core JSX type is web-specific, and part of
solid-js
. it gets used in a few places, including the type definition of things like theComponent<>
type and the control flow primitives.Because the runtime implementation is still doing the right thing, this can be worked around by allowing the dom types and then overriding them wherever you need to use them, but this comes at the cost of extensibility (can't make a solid-js library without depending on the web types) and maintainability.
Your Example Website or App
https://stackblitz.com/edit/solidjs-templates-s9fb1b?file=build.log&view=editor
Steps to Reproduce the Bug or Issue
"lib: ['ESNext']"
in the tsconfigpnpm build
Expected behavior
It should be possible to use the core reactive library without depending on the dom. likewise, it should be possible to use an entirely separate universal renderer without pulling in the dom types.
Screenshots or Videos
No response
Platform
all
Additional context
This is a larger task. It may require backwards-incompatible changes, and it would need input from core maintainers. I have some thoughts on how to approach this, I'll leave them in a follow-up comment
The text was updated successfully, but these errors were encountered: