[labs/context] Can providers use the value they provide?

[joezappie]

I have an element that is providing some async loaded data from an API. I have children inside the element consuming the context, which is working.

I need my provider to also use the data being provided in the context, but it the property just comes back undefined?

import { userContext } from './contexts/user.js';

export class UserView extends LitElement {
  @property({ attribute: false })
  @provide({ context: userContext })
  user;

  render() {
    return html`
      <user-contact></user-contact>
      <div>${this.user?.name}</div>
    `;
  }

  async connectedCallback() {
    super.connectedCallback();
    const user = await App.client.service('users').findOne(this.id});
    this.user = user;
    console.log('provider', 'user', user) // not undefined
    console.log('provider', 'user', this.user) // is undefined?
  }
}

Logging out the loaded user, its undefined. The child user-contact that @consumes the userContext, gets the data.

Is this correct? The documentation show adding @property along with @provide, so why isn't the value available in the provider element via this.user?

[augustjk]

You need the flip the order of the decorators.

export class UserView extends LitElement {
  @provide({ context: userContext })
  @property({ attribute: false })
  user;

  ...
}

[augustjk]

Hmm you're totally right. It looks like specifically the @provide decorator does not work with babel, but replacing it with the ContextProvider does work.
https://codesandbox.io/s/old-architecture-vvkx0x

[augustjk]

It is actually really weird. @provide decorator does not work on it's own, but if you combine with the @property decorator before it like your original, it does seem to provide the context.

[joezappie]

Glad I'm not just crazy. I was so confused on why it didn't work with the examples in the readme but did (kinda) work with property declared first.

Would you like me to open an issue for this? I think I read the decorators are kind of on a development freeze until the decorator proposal is finalized, but does this warrant a fix? My workaround is just to have my providing class have two properties so its not a roadblock but would be nice to not have to do this:

@provide({ context: userContext })
@property({ attribute: false })
userProvider;

@property({ attribute: false }) 
user;

async connectedCallback() {
    super.connectedCallback();
    this.user = await App.client.service('users').findOne(this.id});
    this.userProvider = this.user;
  }
``

[augustjk]

I filed it here #3806
Thanks for reporting and narrowing down the repro!

I'll try and take a look later to see if it might be a quick fix but since there is a workaround priority is not high.

Another workaround would be to use the ContextProvider reactive controller as well. The double decorator seems less desirable as a workaround as it feels like relying on buggy behavior to make the decorator work.