Requiring "solid-js/web" on electron (with nodeIntegration) makes it think I'm on the server

[mauricioszabo]

Describe the bug

I want to use SolidJS in an Electron. Using require('solid-js/web').isServer returns true, which means I can't use render and other web-related code.

I can work-around by requiring solid-js/web/dist/web.cjs but seems fragile...

Your Example Website or App

https://github.com/mauricioszabo/solid-electron-error

Steps to Reproduce the Bug or Issue

Inside an electron app with nodeIntegration: true try to require solid-js/web. The contents of isServer is true

Expected behavior

I expect require('solid-js/web') to always require "web" stuff, or at least have something like require('solid-js/browser') that always points to browser, and require('solid-js/server') that always points to server

Screenshots or Videos

No response

Platform

• OS: Ubuntu 12.10
• Browser: Electron 12.0

Additional context

No response

[edemaine]

This is the normal behavior in Node. Currently, on Node, importing solid-js itself gives you an SSR build which has no reactivity. So solid-js/web can't "just work".

Importing directly from solid-js/web/dist/web.cjs or solid-js/web/dist/web.js (ESM) is one current workaround. Another way to set a Node condition of "browser" (via -C or NODE_OPTIONS), but I'm not sure whether this would interfere with Electron.

I agree that this situation is pretty annoying for using reactivity on Node, but we need an actual proposal for behavior that still enables SSR work.

[mauricioszabo]

The problem is that I can't use templating libs like h because the also require solid-js/web :(

[mauricioszabo]

But I actually don't get it - why can't Solid have two different requires, one for SSR and one for Browser? Why they need to be the same path? Is there a reason for that?

[edemaine]

I think the reason is "being isomorphic". Usually you have one file define a component, and that file needs to be loaded on both client and server for SSR. And it needs to import ... "solid-js" and do different things on each side.

I think Node conditions are a good way. I just don't like that you need to set a condition of "browser" to get server-side reactivity. Personally I'd prefer if you had to set a condition of "ssr" to opt-in to SSR, and the default Node import would just give you reactivity out of the box. But we might need to find something more backward compatible, like a "reactive" condition to tell Node to just load the client build. (I assume you don't need SSR in an Electron context.)

[mauricioszabo]

I think I may be missing something: this code does not work on NodeJS, for example (pure node, no Electron):

const h = require('solid-js/h');
const s = require('solid-js/web');
function A() { 
  return h('div', {}, 'Hello, world!') 
}

s.renderToString(A)

It fails with "Uncaught TypeError: Cannot read property 'has' of undefined". I found that the trouble is that solid-js/h actually loads solid-js/web and then uses web.SVGElements - which is undefined...

Which is to say: as of now, h(...) is not working, so the API does not seem "isomorphic" really... I'm not sure how to proceed from here...

[edemaine]

It seems that Electron might define a Node condition "electron". If true, perhaps Solid could be modified to export the client build in this case, as I can't imagine it being useful to do SSR in Electron?

[Genuifx]

You can split your UI and backend in electron, simulating the network's C/S artfs. then use solid at your UI part.

[ryansolid]

Personally I'd prefer if you had to set a condition of "ssr" to opt-in to SSR, and the default Node import would just give you reactivity out of the box. But we might need to find something more backward compatible, like a "reactive" condition to tell Node to just load the client build. (I assume you don't need SSR in an Electron context.)

Me too but I wanted it to be consistent with legacy. Pre esm and export conditions having the browser field was the pattern. Which makes sense. Package.json was built for npm, ie node.

[mauricioszabo]

So, after talking in Discord, I decided to make some experiments with a greenfield Electron app. It actually doesn't work, even if I "patch" solid/h to require the browser target - the UI renders, but it does not react in any way: https://github.com/mauricioszabo/solid-electron-error

To run, just install packages and run with npm start. The relevant code is on the view.js file.

[mauricioszabo]

Also, updating what we were discussing on Discord here: I'm trying to use SolidJS to make some changes in an Atom plug-in, so I can't really change NODE_OPTIONS or things like that (because that's handled by Atom itself). I also can't use JSX because the plug-in is written in ClojureScript, and there's no way to return a JSX content inside ClojureScript, unfortunately...

[ryansolid]

So, after talking in Discord, I decided to make some experiments with a greenfield Electron app. It actually doesn't work, even if I "patch" solid/h to require the browser target - the UI renders, but it does not react in any way: https://github.com/mauricioszabo/solid-electron-error

I haven't pulled this down but if I were to guess it's because solid-js/web references solid-js directly. So even with the client version of web we are getting the server version of solid's core. The server version is non-reactive which would explain no updates. Short of using conditions, you'd need to alias all the references. This is how we landed on conditions in the first place. Trying to get this stuff to play nice for isomorphic SSR was a pain. As it turns out going the opposite direction is similarly so.

[mauricioszabo]

you'd need to alias all the references
How do I do that?

Also, is there a way to make Electron behave as if it's always a web version? I'm not sure why one would want to use SSR on Electron...

[ryansolid]

you'd need to alias all the references

How do I do that?

Depends on the bundler being used.

Also, is there a way to make Electron behave as if it's always a web version? I'm not sure why one would want to use SSR on Electron...

But this I think we can do. It has to be how others solve this because we aren't the only ones with this issue for sure. Maybe not export conditions but stuff like the browser field predate this. Targets like workers sometimes need similar consideration. My guess is electron sets node which is why we don't get the client version which is the default or it uses the main field export directly which would also do this. The latter I imagine is more likely so, let me see what others do.

Hmm.. this is dated, using webpack with aliasFields https://medium.com/@dylanavery720/marko-marko-3-electron-webpack-84e3edbe90cc

This is documentation from webpack on how to set conditions: https://webpack.js.org/configuration/resolve/#resolveconditionnames. In which case we'd want browser. In the list.

Sorry lack of familiarity with electron specifically and the build process. But most bundlers have the ability to set these things.

[edemaine]

Me too but I wanted it to be consistent with legacy. Pre esm and export conditions having the browser field was the pattern. Which makes sense. Package.json was built for npm, ie node.

Yeah, makes sense. Another option would be to publish as a totally different NPM package. solid-js could remain the SSR-capable version, while @solid.js/solid or something like that (@solid.js/reactive? @solid.js/nossr?) could be the always-reactive never-SSR version. Then we wouldn't have to rely on Node conditions... I think this would be great for using Solid reactivity into Node in general (without GUIs) and it would fix this particular problem easily too.

[ryansolid]

@edemaine That'd be fine for the reactive stuff. Like people want to just use reactivity.

But like this case here we actually want web as well. So references in web have to change as well. So I don't think that actually helps a ton here, or testing envs or any of the typical Solid workflows.