Proposal for easy Solid reactivity on server

[edemaine]

When used outside the browser, Solid is currently "tuned" for SSR. If you want Solid reactivity in Node, for example, you need to declare a Node condition of "browser", which is potentially inaccurate (maybe you want non-DOM reactivity but don't want other packages to think you're actually on a browser) and sometimes difficult (e.g. Meteor and old Electron don't support Node conditions). It's also a frustrating initial experience: a natural way to try playing with Solid reactivity is in Node, but new users are continually surprised that there's no reactivity despite calling createEffect etc.

Goals of this proposal:

• Simple out-of-the-box experience that supports reactivity in Node and SSR with no configuration.
• High performance, including on the server.

Proposal:

• The main build of solid-js would include two builds — what's currently the browser build and what's currently the SSR server build — and a wrapper layer that decides which to call.
• The default behavior of createEffect etc. (as provided by the wrapper layer) is to use the browser/reactive build. As a result, Solid is always reactive out of the box with no configuration/effort.
• renderTo___ SSR functions create roots with a special ssr flag set to true.
• The wrapper layer actually dispatches createEffect etc. calls to the appropriate build according to this flag (depending on the current Owner). As a result, SSR works too — without reactivity and using the string-concatenation renderer — with no configuration/effort.
• createSignal will need some tweaking for this to work, as signals don't have owners (and signals are often top-level, before you've "declared intent" by calling renderTo___). We'll need to always use the browser build for createSignal. To remove reactivity in SSR mode, the signal setter function will need to detect whether we're in SSR mode and skip dependency tracking in that case; alternatively, perhaps it's enough to just not set Listener when in SSR mode, and the browser signal setter code can work as is.
• To avoid including the two builds in the server (e.g. for edge workers where you really want to avoid those kB, or if you want to avoid the if (Owner?.ssr) checks in the wrapper layer), you can specify Node conditions of say "ssr" or "no-ssr". Each of these conditions forces the Node build to include only a single build with no wrapper, equivalent to the current behavior with no condition and with "browser" condition set respectively. We can also define the "browser" condition to imply "no-ssr".

Based on Discord discussion with @fabiospampinato, who came up with the main idea here, but looking back I see @trusktr had pretty much the same idea in a Solid Everywhere discussion. I'm just writing this down carefully.

[edemaine]

Incidentally, I think it really makes sense to include both builds on the server (in general). If you want to do SSR but also want server-side reactivity, e.g. to automatically push data to clients across web sockets, then you want the SSR rendering to not run effects for example, but you want the server-side functions to run effects. This is exactly what this proposal allows, with optional optimizations for cases where you need only one build.

[trusktr]

I really agree that trying to import solid-js in Node should not give you the no-op SSR API by default. SSR applications should have an SSR-specific opt-in for that.

We really need this, and we really need to teach people how reactive patterns are incredibly useful outside of a Solid component. Reactivity is nothing specific to web components at all, and enabled clean code.

I signed up to give a talk about dep-tracking reactivity at Meteor Impact on how it cleans up code compared to other patterns. Let's see if it gets accepted.

I would love to show Solid.js alongside Meteor Tracker (cc @ryansolid) but as soon as people start trying to import it outside of a web context, they are going to fumble.

[trusktr]

Another case is that we don't want any other libs (f.e. any Solid components, custom elements, loaded into Electron and it thinking we're in Node so it doesn't work. I haven't tested this yet, but I'm fairly certain it won't work because the detection mechanism is in package.json exports currently, and that doesn't detect Electron.

and a wrapper layer that decides which to call.

I believe we should avoid auto guessing. It is bound to fail I think. Instead SSR should be explicit depending on tooling.

First, we'd make solid-js package.json exports point to only the regular solid-js. Then this will never fail to give people the real solid-js API.

Then, people configure SSR based on their tooling (and we document how, and/or provide starters and Solid Start).

F.e. Webpack users can output multiple bundles. Webpack users would have:

• entry for client and SSR, both import App.tsx for example
• SSR entry is compiled with solid-js aliased to the SSR build, while client bundle is not.
• one more entry if they want server side logic with solid-js, without any alias.

Similarly with Vite and Solid Start setup.

The default would be that, like any regular lib, if you simply import solid-js, you get solid-js, no surprises. SSR is a special and additional case.

[edemaine]

I agree that I'd prefer this over the current setup, but it doesn't handle the case where you want to do both SSR and reactivity on the server, as in this post. For example, I'd like to use Solid reactivity for reactive databases or web socket content, but maybe still want to do SSR for rendering a page. The original proposal handles this.

[trusktr]

Hmm, that's true, and you want the code. I think something like createServerSideRoot is the only way then.

[trusktr]

• renderTo___ SSR functions create roots with a special ssr flag set to true.

Hmm, this is not guessing though, and might work, although it adds to the implementation of Solid, rather than build tool configs.

So basically we import and use Solid APIs anywhere, except that specifically inside a SSR root it short circuits to the no-ops. 💭

I'm not sure which is better. Less implementation, specific build configs? Or the SSR root with more implementation inside main solid-js?

An upside of the conditional checking in SSR roots may be we can eliminate the standalone SSR code, have it all in one place, and we do not need two separate builds.

• To avoid including the two builds in the server (e.g. for edge workers where you really want to avoid those kB, or if you want to avoid the if (Owner?.ssr) checks in the wrapper layer), you can specify Node conditions of say "ssr" or "no-ssr". Each of these conditions forces the Node build to include only a single build with no wrapper, equivalent to the current behavior with no condition and with "browser" condition set respectively. We can also define the "browser" condition to imply "no-ssr".

I think the SSR root idea entirely prevents us from having to worry a out this bullet point, because we just have a single build, a single solid-js lib, and only the usage of the SSR causes the no-op context.

Either way, with build configs per build tool, or with SSR root, we can just simplify package.json and make it minimal without it knowing anything about SSR.

[trusktr]

Random side-note, but importing solid-js/web in Node.js has no render function exported, resulting in errors. Shouldn't that at least be a no-op, or aliased to one of the other render* functions, for the time being @ryansolid ?

[trusktr]

I'm not yet sure how to import solid-js/web in a TypeScript project in Node.js (but not use it, because I won't run custom elements during SSR). The issue is that importing solid-js/web/dist/web.js directly has no type defs, and I can't add the module type def for some reasons.

I tried changing

import {render} from 'solid-js/web/dist/web.js'

to

import * as web from 'solid-js/web/dist/web.js'
const {render} = web

which gets around the error

file:///Users/trusktr/src/lume+lume/packages/element/dist/LumeElement.js:7
import { render } from './web.js';
         ^^^^^^
Uncaught:
SyntaxError: The requested module './web.js' does not provide an export named 'render'

but then that introduces a new error

file:///Users/trusktr/src/lume+lume/node_modules/solid-js/html/dist/html.js:1
import { effect, style, insert, spread, createComponent, delegateEvents, classList, mergeProps, dynamicProperty, setAttribute, setAttributeNS, addEventListener, Aliases, PropAliases, Properties, ChildProperties, DelegatedEvents, SVGElements, SVGNamespace } from 'solid-js/web';
                                                                                                                                                                 ^^^^^^^
Uncaught:
SyntaxError: The requested module 'solid-js/web' does not provide an export named 'Aliases'

---

Probably known already, but to summarize why the workarounds won't work well:

• Setting node -C browser may introduce other problems while only differing behavior is needed specifically for solid-js.
• Modifying solid-js package.json to change the exports field won't work for apps with Solid SSR that need to import custom elements like LUME's and still use Solid SSR.
• Importing from "solid-js/dist/solid.js" when used along side other libs that import solid-js directly will cause duplicates and reactivity will fail to work (effects won't run).
  • Type declarations are an issue, causing other complications with TS

---

Perhaps the best short term solution is to simply add type defs for all output files in the solid-js package, then at least people can import things like solid-js/web/dist/web.js (knowing it is client-side only).

[trusktr]

@ryansolid @edemaine Here are the high level issues that I think we can solve all at once:

1. Update to a better ES Module layout to avoid issues with tools that don't expect all the intricacies of Node's ESM. Try to follow a simple layout that is most compatible with vanilla ES Module spec (non-Node).
2. Do not use exports for the purpose of SSR vs Client. Tools should configure the correct entry points to use for different pieces of code, or other opt-in methods. The default simple case should just work (f.e. import Solid APIs naively in Node.js and they simply work).
   a. Perhaps the above createServerSideRoot idea can be an alternative to tooling config
3. Do not export the same-name dependencies from multiple places (for example, both solid-js and solid-js/web export something with the name createComponent). Some tools like Vite (Rollup) and TypeScript throw errors for duplicate imports/exports, for example if a package re-exports both solid-js and solid-js/web like this:

   export * from 'solid-js'
   export * from 'solid-js/web' // Error :(

4. Make isomorphic modules have the same exports (aliased to other exports, or no-ops), otherwise import {render} from 'solid-js/web' throws an error because there is no render export in SSR mode.

After these changes, Solid will be much more compatible with ESM tooling and environments, and when we import something any solid-js path we will always get what we expect, unless we explicitly opt into SSR via tooling config.

[trusktr]

The main question is, do we want to just forgo having to separate sources for SSR vs client, merge them, and have something like a createServerSideRoot function?

Or, perhaps the different render* function determine the mode?

[trusktr]

Note Native browser ESM gives errors on duplicate export names. Test output:

Uncaught SyntaxError: The requested module './combined.js' contains conflicting star exports for name 'foo' 

[edemaine]

The main question is, do we want to just forgo having to separate sources for SSR vs client, merge them, and have something like a createServerSideRoot function?

Yes, I had in mind createRoot(..., {ssr: true}) and that this would be called automatically from SSR functions renderTo___ (as opposed to render and hydrate which ought to be called on the client).