Open Alloyed opened 9 months ago
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
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.
This has the benefit of only needing one generic, at the initial createRenderer method. but implies runtime changes that the other solutions would not.
Following... Relevant for https://github.com/lightning-js/solid which uses Universal Renderer and no DOM elements.
Describe the bug
This is a continuation of: https://github.com/ryansolid/dom-expressions/issues/277#issuecomment-1765059926
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