Labs Feedback: @lit-labs/context

[justinfagnani]

The @lit-labs/context package is a set of controllers and decorators for using the Context Protocol as defined by the Web Components Community Group. This protocol lets elements provide and consume data in its subtree without data-binding.

We want to collect your feedback on your experiences with @lit-labs/context as we iterate on it according to our Lit Labs process and move the package towards possible graduation or retirement.

• Status: Near graduation
• Major known issues:
  • [labs/context] ContextRoot will duplicate tracking a context-requesting component which is connected multiple times #2765
  • [labs/context] Add performance tests #2762
  • [labs/context] SSR compatibility #3301
  • [labs/context] lit.dev documentation lit.dev#952
  • [labs/context] @contextProvided and @contextProvider decorators pollute base class when sub-classing #3296
• Issues: [labs/context]
• Docs: README
• npm: @lit-labs/context

Please try @lit-labs/context and tell us about your experience. Leave comments with your thoughts; highlight what issues or missing features you're blocked on; give a link to a project that uses it; etc.

And so we can have some numbers to look at, you can add reactions to this comment to indicate your experience with this package:

🚀 I have tried this package and it works great. I need it. Ship it!
👍 I have tried this package and it seems like a good idea.
😕 I have tried this package and would use it, but it has serious bugs or missing features.
👀 I am interested, but haven't tried the package yet.
👎 I'm not interested in this package.

Note: other reactions like 😄, 🎉, and ❤️ don't mean anything as part of this scheme. You probably mean, and please use, 🚀, 👍, or 👀. One exception is @benjamind who contributed this feature and is probably excited that we're taking steps to graduate it, but doesn't want to vote on the readiness of his own code :)

[christophe-g]

@lit-labs/context is great, thanks you so much !

I will happily switch my " 😕 I have tried this package and would use it, but it has serious bugs or missing features." vote to 🚀 once #3296 is fixed (for the moment, this issue is breaking our app).

I am not worried / impacted by the other issues listed above.

Prop drilling was (still somehow is, as our migration to using context is still undergoing) a real nuisance for our accessible survey application (accessiblesurveys.com or idata.tools):
some high level state information are set/defined a the form level (language, active accessibility mode, and many more). They needs to be passed to deeper nested components so as to adapt the rendering / featuring. One of the problem with this is some intermediary components hold this type of information as property, just to pass it down. Maintenance of such approach is not great.

We tried a couple of (in house) approach to mitigate this, @lit-labs/context is more elegant.

We are also using context to map nested references of a json database (firebase realtime db and firestore) to the dom tree. It is working quite well.

[justinfagnani]

@christophe-g #3296 is fixed now :)

[jrencz]

At first an important disclaimer: I have close to zero experience with lit - I started 2 days ago.
I have long (10+y) experience as web developer apart form that

What I found missing (or maybe just not documented enough?) is control over what takes precedence - provided context or locally-defined value

My setup is a demo with many copies of the same component.
Over them all I have a context provider that sets the same values for them all
I tried to override what provider set.
It works OK if I apply change to a single element AFTER they all connect, once everything is stable. If I set attribute then the element I just set attribute on gains different value of (previously provided) attribute.
But - and that's the part that I understand why it works like that, but I think there might be a way to control it - I'd expect that if I set an override then a new value from provider won't replace the value locally-expressed via attribute.
And in general there's such subscribe

Off course that can be managed inside context consumer, by splitting into 2 properties - provided and related to attribute, and manage state locally.

I propose that subscribe might be extended not only to express boolean, but some policy flags, e.g.: subscribe if there's no locally set value in attribute (makes sense unless @property({attribute: false})

But It's definitely worth to ship it even without the detail I described, since delivering props' defaults (which is the use case I worked on) is just one of the use cases for context provider

[malobre]

This is working great, one nitpick: ContextProvider(..) parameters meanings beyond the first two are not intuitive, it would be better to use an options object, i.e:

ContextProvider(
  host: HostElement,
  context: C,
  options?: {
    callback?: (value: ContextType<C>, dispose?: () => void) => void,
    subscribe: boolean = false
  }
)

[malobre]

Fixed in #3632

[mmcnl]

In the Provider example here, is the logger property missing a @property decorator? ie currently it has only this

  @provide({context: loggerContext})
  logger = new Logger();

[grokwich]

I'm a Lit beginner, but this doc issue burned me badly. My impression from the doc was that @provide/consume included @Property behavior so i always left it off, then burned a lot of time trying to understand why the properties were always "undefined" even though the context events/callbacks where being fired?

[justinfagnani]

@property() makes setting the property update the host - this is needed if the host uses that property itself in render() or another lifecycle callback. It isn't always needed though. Sometimes you use @provide() just to provide a value to descendants.

So I'm not sure if that example is rally missing the @property() decorator because in that example the host doesn't use the logger to render, and doesn't necessarily want to update itself when the logger changes.

[pragmasoft-ua]

I seems found one serious shortcoming of the Context protocol.

The problem is, that it depends on the order of the initialization of participated elements.

Precisely, it expects, that context provider is initialized before context consumer, otherwise it will miss the context-request event from the consumer.

If consumer is in the shadow dom of a provider, this is always the case.

Though, if both provider and consumer are in the light dom, this may not be the case anymore, even if provider is a consumer's parent.

I created two elements and a demo page like this one:

<html lang="en">
  <head>
    <link rel="stylesheet" href="./src/index.css" />
    <script type="module" src="/src/child-element.js"></script>
    <script type="module" src="/src/my-element.js"></script>
  </head>
  <body>
    <my-element id="my">
      <child-element id="child"><h1>Vite + Lit</h1></child-element>
    </my-element>
  </body>
</html>

and got the following initialization order:

child-element constructed child
child-element connected child
my-element constructed my
my-element connected my

If I change the order of scripts in the html page, that is, my-element.js module is loaded before the child-element.js, the initialization order changes to

my-element constructed my
my-element connected my
child-element constructed child
child-element connected child

[jrencz]

Do I get the idea right that you propose to ship a copy of ContextRoot code in each entrypoint module and the first one that arrives win (installs the ContextRoot on <html>)? That's an interesting idea but it will have an overhead. Additionally you will have to make your bundler (if you have one, off course) to include that code in each output instead of making a shared module out of it

I solved it differently for my setup: I have a single wrapper component what is said to be the "Wrapper of them all" and I delay registration of all the rest until after that one registered (technically: my own replacement for @customElement) It worked for me but it also has a cost: things appear a bit later. For me thats not an issue

[pragmasoft-ua]

I ended up with the following solution, which in my opinion has minimal overhead.

I added ContextRoot initialization as a side effect to the same module where context is created, since it is imported by both provider and consumer modules and thus is executed before them and only once:

import { ContextRoot, createContext } from "@lit-labs/context";

console.debug("my-context initialized");

new ContextRoot().attach(document.documentElement);

export const myContext = createContext("my-context");

[jrencz]

Seems OK in authored code. Yet examine the bundler output if you have one and if you generate multiple entrypoint modules it's likely that bundler will spot that @lit-labs/context is a common dependency and it will not inline it, instead it will likely leave an import - you will then anyway have an uncontrolled delay in loading @lit-labs/context

[pragmasoft-ua]

Checked the bundler output, works well, at least with the only entry point, here's my demo project just in case somebody needs an example.

[jrencz]

You're right: if you build with Vite then this seems to be the most efficient way.

From what you wrote

we're going to ship our components to 3rd parties

I thought you have a setup similar to mine, where each component (not HTML document) is Rollup's input and I ship components as directory of modules to be loaded in fashion very much like described in https://shoelace.style/getting-started/installation/index.html#cdn-installation-easiest