Lit Context with only js

[igmansilla]

Hi! i'm curiuos in how to implement lit element context only using javascript, because i read the documentation an only found a description of the implementation in typescript. Thnks!

[justinfagnani]

You can use the library without TypeScript. Just don't use the decorators. The docs may have types in them, but you don't need the types.

[augustjk]

We also added a context playground example that you can toggle to JS mode to see how it can be written without decorators.
https://lit.dev/playground/#sample=examples/context-basics

[Noleli]

I don’t know whether this would be considered best practice, but here’s my approach for using Context without decorators.

Provider

class ParentElement extends LitElement {
    static properties = {
        data: {}
    };

    _dataProvider = new ContextProvider(this, dataContext);

    willUpdate(changeProperties) {
        if(changeProperties.has("data")) {
            this._dataProvider.setValue(this.data);
        }
    }

    render() { … }
}

Consumer

class ConsumerElement extends LitElement {
    static properties = {
        data: {}
    };

    _dataConsumer = new ContextConsumer(this, dataContext, value => {
        this.data = value;
    }, true);

    render() { … }
}

---

I will say, it’d be nice (or at least feel somewhat more idiomatically Lit-like to me) if, when a change to a subscribed context triggered an update of a consuming component, that context key got added to the changedProperties map. That way you could assign the new value to the reactive property in the consumer’s willUpdate() (parallel to how I’m doing it in the provider) without having to rely on a callback. (Yes, I know that would trigger another update cycle; it just feels more Lit-ish to me ¯_(ツ)_/¯)

[augustjk]

On the consumer side, anytime you'd want this.data you can do this._dataConsumer.value instead, so there's no need to do a callback to sync it to a property.
You could also define a getter that returns this._dataConsumer.value.

[Noleli]

Thanks, Augustine. The docs do say it’s reactive, so I’m not sure why I added the extra step. :) I think it was because I wanted it to feel more like the example with decorators where a property has both @consume and @property.