e111077 · HackerTrans

il y a 2 ansdiscuss

politics

il y a 3 ansdiscuss

In terms of low decoupling:

It sometimes makes working with _slotted_ children in a non-lock-in way difficult in terms of state synchronization as opposed to props.children in React. The solution here in an app would be to use a state manager, but it's much more difficult for components that do not want to require the user to use a state manager e.g. design systems.

Additionally, hydration and customElements.define() upgrade order is a different consideration compared to other mono-state frameworks when it comes to SSR.

In terms of state management:

There are plenty of tools out there like lit-mobx shopped by Adobe. The team has also made some examples that show how easy it is to integrate your own state manager into Lit using ReactiveController such as Redux. There is also work being done such as example implementations of Preact Signals integration:

https://github.com/lit/rfcs/blob/preact-signals/rfcs/NNNN-pr...

e111077

il y a 3 ansdiscuss

I worked on adding some of these. We pull them from each of the company's respective brand identity page + some manual SVG cruft elimination to decrease code size.

e111077

il y a 3 ansdiscuss

Yeah, this is not an issue for very well-designed WCs like https://shoelace.style or in cases where it's not necessary like https://modelviewer.dev/

e111077

il y a 3 ansdiscuss

unstyled web components: look into ING Lion Web Components (Lit-based) or @generic-components/components (vanilla)

e111077

il y a 3 ansdiscuss

Likewise with Lit, but that is besides the criticism that he was making earlier

e111077

il y a 3 ansdiscuss

In that case why not just SSR lit on the backend and send that? It sounds like an unfair criticism otherwise

e111077

il y a 3 ansdiscuss

When one writes `import 'lit'` the browser doesn't know where Lit is. This is called a bare module specifier vs an absolute import specifier:

  import '/home/user/project/node_modules/lit/index.js'

A relative specifier:

  import '../node_modules/lit/index.js'

Or a URL Specifier:

  import 'https://unpkg.com/lit?module'

So you have four-ish options to tell the browser where to look for 'lit':

1. Use a server that will use the node module resolution algorithm and transforms it to a relative specifier as it encounters the import (transform/build-ish?)

2. Use experimental "import maps" to go fully buildless to tell the browser where to point that bare module to (buildless)

3. Bundle all your code (build step)

4. Use a bundle from a CDN

Here are some examples of each:

Server that transforms import specifiers (lit.dev does this by default):

https://lit.dev/playground/#gist=9092862a77acf73dd1e6faa73a3... (build-ish)

Import Maps (2):

https://lit.dev/playground/#gist=0c4f66396b333c82cb27e7dd3b2... (buildless)

https://lit.dev/playground/#gist=91c0b286698612b013eb81881ff... (build-ish)

Url Specifiers (2):

https://lit.dev/playground/#gist=05655736300f0425644e61a6264... (buildless)

https://lit.dev/playground/#gist=6d23e8e8dadacd7488bdec81d0f... (build-ish)

hope this helps with some of your questions

e111077

il y a 3 ansdiscuss

Web Components are Custom Elements + Shadow DOM, and this makes half of that equation server-side. The other half works as a client-side hydration strategy until they churn out whatever Declarative Custom Elements would look like.

comments