Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using typescript, solid-js depends on DOM elements, even outside of "solid-js/web" #2051

Open
Alloyed opened this issue Jan 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@Alloyed
Copy link

Alloyed commented Jan 26, 2024

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 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.

Your Example Website or App

https://stackblitz.com/edit/solidjs-templates-s9fb1b?file=build.log&view=editor

Steps to Reproduce the Bug or Issue

  1. Remove 'dom' from your global type definitions. (in the repo that is done by "lib: ['ESNext']" in the tsconfig
  2. pnpm build
  3. observe build errors. examples:
node_modules/.pnpm/solid-js@1.7.6/node_modules/solid-js/types/jsx.d.ts(9,19): error TS2304: Cannot find name 'Element'.
node_modules/.pnpm/solid-js@1.7.6/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

@Alloyed
Copy link
Author

Alloyed commented Jan 26, 2024

Approach 1. Move everything into solid-js/web

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.

@ryansolid ryansolid added the enhancement New feature or request label Jan 26, 2024
@chiefcll
Copy link
Contributor

chiefcll commented Apr 5, 2024

Following... Relevant for https://github.com/lightning-js/solid which uses Universal Renderer and no DOM elements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants