[lit-labs/context] Providing an object

[joezappie]

I'm trying out context but I'm curious how it can handle objects as the "value". For example, I want to have a timer that stores both the elapsed time and a status for if its stopped, paused, running. If I create a Timer object that is provided as the initial data, is there anyway for that object to tell the context that its value has updated? I see that the provider has a setValue command but that means remaking the object every time the timer counts up?

Here's a lit playground example of what I'm trying to do. I have a Timer class that handles keeping track of state and intervals. A button element that shows the control buttons, a display element that shows the timer count and an app container.

Lit Playground Example

Also, app-container in this case is supposed to be generic. While its a provider for the timer context, I don't think it should have any part in the timer logic. Its just the provider as its the root container for the app. Ideally I'd also provide user contexts, organization contexts, and other global app data from app-container. I might be misunderstanding the use case of context however.

TLDR

I think provider logic should be able to be separated from the element that's providing them (maybe it already is?). In this case, I'd want to provide a bunch of contexts from the root application element for data that's specifically global, such as the current user, what organization/workspace their in, settings such as user preferences or defaults. What I wouldn't want to happen is to have to make a separate element for each of these contexts and nest my entire app like:

<app-container>
  <timer-context>
    <user-context>
     ... Actual app code
    </user-context>
  </timer-context>
</app-container>

[vdegenne]

This is interesting, I had the same interrogation last time, but of course the context only reacts when your object reference changes (just like when you use a decorator like @state). But here are some suggestions if you need some ideas on how to implement this pattern yourself:

1. Turn your Timer class into a controller (Lit/Controllers) and create accessors for both value and state so when one of the two properties changes you can call something like this.host.updateContext() and in your host you will have this function:

class AppContainer {
  private _timerController = new Timer(this);

  @provide({context: timerContext})
  @property({attribute: false})
  public timerContext = { timer: this._timerController }

  updateContext() {
    // By changing the reference  your context will trigger children updates.
    // Children can then access `this.timerContext.timer`
    this.timerContext = { timer: this._timerController }
  }
}

Not sure if that's the best way to do that but one I can think of.

2. You could also implement your Timer as a Redux component and use connect from the pwa-helpers API....

[vdegenne]

I am actually working on a project that can ease out this process when using Lit. I'll tell you more when I finish 😛

[joezappie]

Nice! I didn't think to use a controller for my timer class.

The only thing I'm not a huge fan of is the fact that AppContainer still needs a function manually added to it to update the context. This becomes more complicated the more contexts you add to it, such as in my case a User context or organizational context. This however could be solved by making a simple decorator to auto add that function to the app container:

I'd love to see something built into context directly for handling this. What I'd really like to see is that context providers can be attached dynamically to an element just like a controller can. That way the Timer class itself would be a provider and I can easily remove or add it to my app container after the fact.

The docs do say that ContextProvider is just a reactive controller so I'm looking at just extending that class so that it can call setValue directly but I'd lose out on being able to use the @provide decorator. Maybe in the future, Lit could allow the decorator to specify your own custom provider:

@provide({ context: timerContext, provider: TimerProvider)

Interested in seeing what you come up with!

[joezappie]

Going off of that, I now have a Playground Example for extending ContextProvider directly. I do lose out on built in @provide support but easily could make my own decorator, or maybe Lit/Context would accept a PR to allow custom context providers to be used. I think that opens up a lot of doors.

[vdegenne]

@jrj2211 Hey,
Remember I said I would come back to you when I finish developing a solution I had in mind.
Well time has flew and I was quite busy but I remember this conversation so I am sharing this with you.
Here's the updated Playground.
I think you might be interested about it, I've managed to reduce the code to less than 90 lines, but it's not just about writing less, it's also about having a really easy way to manage states across your elements.

It's still a controller behind the scene, but a multi-host and reactive controller.
In the playground, you can see that all definition is made in the parent class app-container (binding the controller to all consumers in the first update method).
It works because the context is created constructor-wise, but the motivation behind @snar/lit was to have an easy solution to create global shared states across singleton app elements (Here's another playground to demonstrate that, it uses the @withController decorator : demo which in the end is even less code.)

I've dropped the experimental stage, and I started to share it with people, and any feedback is appreciated.

Happy Coding!

[joezappie]

Hey @vdegenne,

Awesome work, looks great from a first glance! Definately improves the readability of all this.

I'll start playin around with this soon, but definately will switch from my reactive controller setup to this. I'll keep you posted if I have any feedback on it.

Thanks!

[joezappie]

I'm playing around with this and the @withController decorator, but for some reason my elements that use the controller aren't getting rerendered when the value is updated. My ReactiveControllers update method is however getting called. Trying to figure out what I'm missing compared to your example.

[vdegenne]

@jrj2211 Do you have a repo so I can see what you are doing wrong (or if there is an issue with the lib)?

[joezappie]

Unfortunately I don't have a repo ATM. The only steps tho should be to create a reactive controller, create a singleton instance of said controller, then pass that into each component with @withController? Anytime any @state or @property is modified then, the lit lifecycle functions should be called in any component with the reactiveController?

I'm going to try the method of manually binding to see if its just an issue with withController for me.