Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[labs/context] @contextProvided and @contextProvider decorators pollute base class when sub-classing #3296

Closed
christophe-g opened this issue Sep 22, 2022 · 3 comments
Assignees

Comments

@christophe-g
Copy link
Contributor

Which package(s) are affected?

Context (@lit-labs/context)

Description

Using decorators to declare context in a sub-class adds it to the base class.

class Base extends LitElement {
	@contextProvided({context: simpleContext, subscribe: true})
	@property({type: Number})
	public value = 0;
}

class Ext extends Base {
	@contextProvided({context: simpleContext, subscribe: true})
	@property({type: Number})
	public valueExt = 1;
}

Any instance of Base will have 2 controllers, its own AND the one declared in the exended class.

Expected behavior: It should only have one controller.

Reproduction

See https://lit.dev/playground/?linkId=8223273#gist=4875267ed996afc7bad538e17fe80907

Workaround

Do not use context decorators when sub-classing, but this is not really a workaround

Is this a regression?

No or unsure. This never worked, or I haven't tried before.

Affected versions

lit: 2.3.1; @lit-labs/context: 0.1.3

Browser/OS/Node environment

Chrome stable latest, linux mint.

@christophe-g christophe-g changed the title [labs/context] @contextProvided and @contextProvider decorators polute base class when sub-classing [labs/context] @contextProvided and @contextProvider decorators pollute base class when sub-classing Sep 26, 2022
@justinfagnani justinfagnani self-assigned this Sep 28, 2022
@christophe-g
Copy link
Contributor Author

@justinfagnani - any ETA on this one ?

I am aware we all are very busy, so asking this mostly for planning purpose on my end.

I can also try to have a go (without fixed promises, given my limited exposure to decorators and current time availability), if any pointer is provided.

@christophe-g
Copy link
Contributor Author

Closing as solved by #3374

@justinfagnani
Copy link
Collaborator

Thanks for following up here @christophe-g !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants