The ideal Solid? (v2, v3, v4, etc)

[trusktr]

I didn't see an official thread for 2.0 ideas, unless I missed it, so posting here (I can move it if needed). But maybe these ideas could even be split across multiple major versions without a rush.

---

I feel like the current signals.ts file is doing too much. I believe the signals+effects reactive pattern, which is like a 100-200 LoC sort of deal, can be in its own file, with primitives exposed from it that allow making the other APIs on top.

Things like Suspense, Transitions (which is confusing because people think about "animation" when someone says "transition", we don't need React terminology), etc, can be implemented "on top" of the core reactive system.

Someone should be able to look at the reactive system and easily understand how easy it is to make dep-tracking reactivity (not the case right now in an almost 2k LoC signal.ts file with much indirection between core reactivity and other features that are specifically for Components).

Top priorities to me are the following (not necessarily in order). What do you see as possible for v2, possible for v3 and later, or not possible at all ("not possible" as in "undesirable", because they're all technically possible)?

1. Simplified project structure as close to vanilla ESM as possible.

The current project structure, based on Preact's project layout conventions (now-dated in the ES Module standard days), with this we will stop being incompatible with various tools and setups, and we'll be generally as friendly as possible to vanilla ES Module users and fully aligned with the most standard of standards, without using the package.json exports field (there's really no need for it other than to forbid people from importing things, and its path mappings only make Solid harder to configure in vanilla ESM and incompatible with tools that still don't understand Node ESM export rules).

Then we build optimizations on top such as building a bundle output, etc, and we'll come to realize that managing this will be simplified. This also ensures that type definitions are always available even in the simplest form of importing Solid (just import whatever from 'solid-js/path/to/whatever' (not just top level) and types will simply always work. We would simply output declaration files in the same structure as source files.

This also simplifies my upcoming goals of compiling a simple TypeScript project structure to WebAssembly and not having to add support for Node ESM rules.

2. Stop custom building of dependencies into the main lib

This kinda goes hand in hand with the previous point. Keep everything ESM. Then optimize the build.

Otherwise this makes dependencies untraceable and difficult to discover because they are "imported" in a very non-standard way using a totally bespoke methodology that tools simply don't understand.

3. Bring tools like dom-expressions into Solid proper.

Encourage contributions, and make people's contributions more visible. I don't think this is really going to stop people from using dom-expressions on its own. It can still be published in a standard way on its own (with standard structure as in points 1 and 2) and people can go ahead and import it.

The Solid.js website does not even have to advertise it. This is only the location where its source lives. It just needs to be easy to find, contribute to, and making it easy to recognize Solid contributors.

4. Deferred effects by default (maybe even no synchronous effects).

This is like every other major framework's move to deferred effects. The same as when React made setState async, for performance (but the way React did that was not very good because it left users with values-in-the-past issue, which grug find very bad).

• Redefining (or deleting) `batch`, and the concept of a new batched effect #943

5. As a consequence of the previous point, the batch API can be deleted

I really do believe there is zero need for this concept to exist at all, except for it being a stop gap way to fix problems caused by the current synchronous-effect implementation.

6. Highly-decoupled reactive system not coupled to all the component-specific features

Build those "on top" separately, in a way that makes it easy to:

7. sell Solid's reactivity as a first-class library on its own

Without all the component stuff. May also go with "rootless effects" while at it.

8. Strict type safety, without dynamic un-typed JavaScript

Then we compile to WebAssembly (and by extension, even native).

[samuelstroschein]

7. sell Solid's reactivity as a first-class library on its own

I have/had the feeling that the reactive system could establish itself as "the standard signals-based reactive system for JS".

Reposting for visibility. Taken from the Discord discussion:

Have you thought about splitting/communicating the reactive system separately from the UI for v2?

Solid JS - The reactive system for JavaScript
Solid UI - The UI framework for SolidJS

This split could drive tremendous growth for SolidJS and thereby also SolidUI.

• reactive systems for JS are emerging. SolidJS could become the de-facto standard for reactive system JS like React is for UI. There is no standard reactive system yet.

• if SolidJS takes off, the UI library will take-off too. The biggest drawback of SolidUI, the ecosystem, becomes smaller + people > using SolidJS will have a higher incentive to use SolidUI.

• nobody understands right now that SolidJS's reactive system can be used in plain JS. The split would communicate that fact.

[samuelstroschein]

Update: I think we have a very sound use-case with https://github.com/inlang/inlang for a reactivity system that works in plain JS with adapters for UI frameworks, or no adapters if Solid UI is used. I can elaborate if the Solid team seriously considers Solid JS vs Solid UI separation.

[ryansolid]

Already confirmed for 2.0. In fact already in progress for experiments the past 6 months. We will have some more updates around this the next month.

[samuelstroschein]

@ryansolid here is a glance at our use case opral/monorepo#1122 (comment).

We are wondering if Solid 1.0 could help out now? Will Solid 2.0 help?

• we need reactivity that works in various web apps that are using React, Svelte, Solid, etc.
• we need reactivity that also works in VSCode/traditional server-side JS apps

[ryansolid]

Note on Signals.ts. I've tried to break that file apart seriously, like multi day effort 4 times now and I can't. There is no way to do it without terrible circular references and maintain treeshakeability. I knew this was coming so I've just given up until we have 2.0 reactivity rewrite. The thing is things like Suspense and Transitions really can't be implemented "on top" or rather writing them on top results exactly like that because they cross cut through core concerns impacting dozens of touch points that are very much internal.
The only way to implement them "on top" is provide the right sort of primitives to rebuild them which requires a different view of reactivity. We believe we have that model and I've written a bit about that with some rough notes found here.

1. Simplified project structure as close to vanilla ESM as possible.

I'm not going to lie. I still really like subpackages. But yes it is getting pretty hefty. With reactivity moving out of the core as well as store it really just a matter of solid-js/web can finally be pulled out I feel. This was something that I wasn't sure about at first but I think it makes sense. Keep in mind h and html both rely on it and universal too are all dom-expressions based libraries. Right now we leverage they all basically have the same build process. If we split it we will have separate packages with similar build processes. There is also some thinking that /h or /html belongs core but these are just extensions of web. Biggest downside of moving web is inconsistent package imports. We have @solidjs/web and solid-js or I suppose solid (we got that off npm, although changing that would reset our download numbers). I don't like @solidjs/core or @solidjs/solid but maybe that is the logical place (again resets our downloads).

2. Stop custom building of dependencies into the main lib

3. Bring tools like dom-expressions into Solid proper.

I hear you. The build process was the best I could come up with at the time while keeping dom-expressions generalizable. The problem of course is that for treeshaking the work you can't have factory functions. You need the code to just be exported and yet I couldn't reference directly so the easiest way to do that is to do a transform on the imports and then bundle it using re-exports. To be fair I haven't found a better way to do this yet. This might mean just retiring dom-expressions but that has been something that I've been hesitant to do because it sparks other projects.

I'm open to bring dom-expressions into Solid organization or even into the mono repo. I think you are right as long as I don't change the package name on npm. The mono-repo might be confusing though. Part of me still wonders if dom-expressions has run its course. It would be much simpler if the runtime was just @solidjs/web for the most part and we just had a project for the compiler projects. I mean that's a topic too.. There is an SWC plugin that is well in the works and basically has all client side Solid features working.

4. Deferred effects by default (maybe even no synchronous effects).

5. As a consequence of the previous point, the batch API can be deleted

6. Highly-decoupled reactive system not coupled to all the component-specific features

7. Sell Solid's reactivity as a first-class library on its own

This effort has already started. We still need synchronous effects for rendering but yes queuedMicrotask, automated batching, an opt in flushSync are all already implemented. Seperate repo with no component-specific features and I see selling Solid's Reactivity system especially on the power of branding under Signals since effectively we are viewed as the originator of them as very strong.

ie.. @solidjs/signals

Keep in mind when I say component-specific features not being there our reactivity has some very interesting core properties that are not found in many systems and are core and essential.

• Ownership/Roots
• Nested Node creation
• Automated Disposal
• Effectful Error Catching
• Reactive Context
• Transitions(Async Transactions)

And some new ones

• Scope Controlled Effect Flushing
• Async blocking graph resolution

None of these is specifically component or UI-based but work off the idea of Effectful Nested Scopes which may represent a UI or maybe something else.

8. Strict type safety, without dynamic un-typed JavaScript

This seems like a good goal. I have no idea how to get there. A lot of the work in 2.0 will make external typing easier but internal is still a big question mark for me.

All around I think we are mostly aligned here. A lot of the community has felt the same pain you have felt so from the requests I feel like this is confirmation that we are heading in the right direction.