this.createEffect() will make an effect that is conveniently stopped in disconnectedCallback. This is useful for creating effects in connectedCallback and then not having to use createRoot and disconnectedCallback to stop them.

Currently:

connectedCallback() {
  super.connectedCallback()
  
  createRoot(dispose => {
    this.dispose = dispose
    createEffect(() => {
      // ...
      onCleanup(() => {...})
    })
  })
}

disconnectedCallback() {
  super.disconnectedCallback()
  this.dispose()
}

Using this.createEffect:

connectedCallback() {
  super.connectedCallback()
  
  this.createEffect(() => {
    // ...
    onCleanup(() => {...})
  })
}

dom is deprecated now, because web includes both SSR (no DOM) and clientside stuff (has DOM).

FUOC is something that people generally wish they didn't have to deal with. To make things easier, perhaps we can add an option that will automatically keep content hidden until async content in a element's ShadowRoot has finished loading.

We need to list @lume/cli as a peer dependency of of @lume/element because @lume/element depends on a certain range of versions of @lume/cli for when it is time to build (with @lume/cli) an application that uses @lume/element with JSX templating. @lume/cli contains the build steps needed to compile the JSX into a form that works with @lume/element.

This isn't an issue if app code uses the html`...` template tag for templating, in which case the compilation of templates happens at runtime, and there's no hard version requirement for @lume/cli in that case.

• update README on how TS users will import types using jsxImportSource in TS 4.1.1+
• describe how props/attributes work

Ideas:

• https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec

This will probably be in a new repo, but it doesn't exist yet.

We can get ideas from https://github.com/mduclehcm/solid-router.

Make a simple abstraction that can take a piece of CSS, generate a stylesheet from it, and provide the end developer a function that can be called in order to pass values for CSS variables/properties.

Initial description of the idea is in postcss/postcss#476 (comment).

Basically given the following CSS,

.foo {
  --some-prop: 1px;
  /* ... styles that use var(--some-prop) ... */
}

we can implement some a tool on the JS side that automatically gives you a simple abstraction:

css = css`
  .foo {
    --some-prop: 1px;
    /* ... styles that use var(--some-prop) ... */
  }
`

// ... call this any time later to update the style's `--some-prop` variable ...
this.css.update({someProp: '10px'})

This will help pave the way towards using reactive variables within CSS styles in a performant way.

Another ideas is we can abstract it so that the css template tag can automatically perform the property update internally:

css = css`
  .foo {
    --some-prop: ${this.foo};
    /* ... styles that use var(--some-prop) ... */
  }
`

// ... call this any time later to update the style's `--some-prop` variable ...
this.foo = '10px'

where this.foo is a reactive property.

Or maybe we just auto-create reactive accessors:

css = css`
  .foo {
    --some-prop: 1px;
    /* ... styles that use var(--some-prop) ... */
  }
`

// ... call this any time later to update the style's `--some-prop` variable ...
this.css.someProp = '10px'

otherwise the following will fail if styles are prepended:

        template = html`
            <!-- Element styles are currently prepended here. -->

            <!-- import a lib, f.e. bootstrap. -->
            <link rel="stylesheet" href="./lib.css" />

            <!-- Because lib.css ends up *after* element styles, element styles do not override lib styles. -->
            <div class="lib-btn"></div>
        `

Current workaround is to define styleRoot where styles will be appended:

        #styleRoot = document.createElement('div')

        get styleRoot() {
            return this.#styleRoot
        }

        template = html`
            <!-- import a lib, f.e. bootstrap. -->
            <link rel="stylesheet" href="./lib.css" />
            
            <!-- Element styles are prepended here in the styleRoot. -->
            ${this.styleRoot}

            <!-- Styles work as expected, element styles overrode lib styles. -->
            <div class="lib-btn"></div>
        `

PR:

• #13

When I open the demo page(https://webcomponents.dev/edit/EJ5VTuaaO0Iwq3APUFMe), the code throws error below.

_$currentContext is not a function
src/index.stories.jsx (12:22)

TypeError: _$currentContext is not a function
at https://webcomponents.dev/42890220-93bd-11ec-b7a1-81c82af0ebbf/web_modules/EJ5VTuaaO0Iwq3APUFMe/dist/index.stories.js:17:19
at story1 (https://webcomponents.dev/42890220-93bd-11ec-b7a1-81c82af0ebbf/web_modules/EJ5VTuaaO0Iwq3APUFMe/dist/index.stories.js:19:3)
at n.parameters.__isArgsStory (https://webcomponents.dev/assets/__virtual_entry_render_addon.hash.js:42:3037)
at https://webcomponents.dev/assets/__virtual_entry_render_addon.hash.js:42:5354
at vo (https://webcomponents.dev/assets/__virtual_entry_render_addon.hash.js:43:1125)

BROWSER: Google Chrome: 98.0.4758.102

This will be necessary in order to support declarative ShadowDOM and to implement SSR. We might want to detect and create ShadowRoots in constructor.

This is a more performant way to share a common styling across instances of a custom element. Not all browsers support it yet, and the API may change a little before the spec settles.

Explainer: https://developers.google.com/web/updates/2019/02/constructable-stylesheets

Polyfill: https://github.com/calebdwilliams/construct-style-sheets