Giters

WebReflection / uhtml

A micro HTML/SVG render

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Import uhtml package in server side

abdolian opened this issue · comments

commented

When I try to import uhtml dependency in a Next project I face with a exception which related to line#371.

const {
  createDocumentFragment,
  createElement,
  createElementNS,
  createTextNode,
  createTreeWalker,
  importNode
} = new Proxy(document, {
  get: (target, method) => target[method].bind(target)
});

My suggestion is:

const document = typeof window == 'undefined' ? {} : window.document;
const {
  createDocumentFragment,
  createElement,
  createElementNS,
  createTextNode,
  createTreeWalker,
  importNode
} = new Proxy(document, {
  get: (target, method) => (target[method] || function () {}).bind(target)
});
commented

I saw it, And I don't need to uhtml-ssr. I use uhtml only for client-side but uhtml is bundled with my nextJs project and make a server-side error.
please look at these links to support client-server-side compatibility.

commented

the second link is just a named export ... not really relevant here, the first one ... if you manually change main to browser, would your nextJs project work?

your suggested solution is not a solution: this module can't work outside a browser environment so either you bring a browser environment in (via LinkeDOM or others) or you use the SSR version or you ... change nextJs way of building things as it uses a file it's not supposed to use?

commented

The second link is only a sample. This compatibility is a typical feature that most libraries have. It's very simple, you can set a path to the 'browser' key in the package.json that works in the browsers environment and define the 'main' key that point to an empty file that exports only types of Hole, html, render, and svg functions.

commented

And the better solution is:
package.json

{
  browser: 'POINT TO uhtml',
  main: 'POINT TO uhtml-ssr',
}
commented

The better solution assumes uhtml-ssr is part of this module/library ... which is not, but there could be some optional dependency to consider ... I'll think about it.

It's very simple, you can set a path to the 'browser' key in the package.json that works in the browsers environment and define the 'main' key that point to an empty file that exports only types of Hole, html, render, and svg functions.

I don't understand the purpose of that ... why should I bloat the module with empty files and things that won't work at all?

Tooling supposes to help developers, not the other way around, imho.

commented

late answer sorry, but this module is front-end or envs with a document which you cna solve by importing a file that does something like:

// actually use LinkeDOM or any other DOM based lib
// as fallback, maybe?
globalThis.document || (globalThis.document = {});

Instrument your env to import that how you like and that's it.

Reason I am not fixing this is that having no document means broken module (or dirty) and I don't want to make uhtml dirty or broken because 3rd party "solutions" cause issues ... in short: I won't fix 3rd party gotchas in here.