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

[RRFC] Better Declarative Host Manipulation #11

Open
e111077 opened this issue Aug 21, 2020 · 8 comments
Open

[RRFC] Better Declarative Host Manipulation #11

e111077 opened this issue Aug 21, 2020 · 8 comments

Comments

@e111077
Copy link

e111077 commented Aug 21, 2020

Description

  • Who: Developers who code declaratively
  • What: Be able to declaratively set event listeners and styles on host
  • Why: Declarative code is great and for northstar transformations
  • Description:

I would like better declarative host manipulation. Often you need to set lots of event listeners on host or even set an inline style on host e.g. transform: translate(x, y). It would be nice to have a declarative way to do this with things such as stylemap or listenermap or something. Perhaps another method alongside render and first render that gets called on each / first render cycle etc.

Or for event listeners maybe even a TS decorator that takes in event name and event options and passes the proper type to the event listener based on the event name.

Acceptance criteria

Be able to set an event listener and a style declaratively on host

@justinfagnani
Copy link
Contributor

justinfagnani commented Aug 21, 2020

I think we might be able to do this with lit-html 2.0 and the attr template tag.

Maybe something like:

class MyElement extends LitElement {
  renderHost() {
    return attr`@click=${this._onClick} style=${styleMap{this._styles}}`;
  }
}

@sorvell sorvell self-assigned this Aug 27, 2020
@sorvell
Copy link
Member

sorvell commented Aug 27, 2020

Yeah, this definitely sounds appealing. We'll evaluate adding this pending core support in lit-html.

There are some tricky issues to work through related to this, in particular there are two actors potentially applying lit-html bindings to the host element, the element author and user. We'll have to make sure that composes well and makes sense.

@e111077
Copy link
Author

e111077 commented Aug 27, 2020

related lit/lit#1139 😜

@e111077
Copy link
Author

e111077 commented Sep 10, 2020

Also a stretch would be to possibly extend this idea to a solution that can work for declarative slot manipulation as well

@jaredcwhite
Copy link

jaredcwhite commented Oct 15, 2020

I'm not sure if this fits in here, but I've been working on a custom subclass of LitElement that can use a MutationObserver to find declarative action attributes and attach event handlers to Light DOM content, as well as provide some shortcuts for running queries…basically allowing LitElement to offer similar functionality to Stimulus.js. I'd love to see more of that sort of thing in LitElement directly…makes integrating app-specific web components with SSR Light DOM much easier.

@jsilvermist
Copy link

Is this something that will be available in lit v2? I like @justinfagnani's example above for declarative attributes and event listeners on host.

@e111077
Copy link
Author

e111077 commented May 25, 2021

Declarative attributes can likely be covered by reactive props with reflect: true. listeners have been proposed here:

lit/lit#1870

IIRC still some design need to be done with the non-TS use case

@sorvell sorvell removed their assignment Sep 8, 2022
@sorvell sorvell transferred this issue from lit/lit-element Sep 8, 2022
@sorvell
Copy link
Member

sorvell commented Sep 8, 2022

Converted to an rrfc since it needs a proposal.

@sorvell sorvell moved this to 📋 Triaged in Lit Project Board Sep 8, 2022
@sorvell sorvell changed the title Better Declarative Host Manipulation [RRFC] Better Declarative Host Manipulation Sep 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Triaged
Development

No branches or pull requests

5 participants