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/eleventy-plugin-lit] Support passing data as properties #2485

Open
aomarks opened this issue Feb 3, 2022 · 6 comments
Open

[labs/eleventy-plugin-lit] Support passing data as properties #2485

aomarks opened this issue Feb 3, 2022 · 6 comments

Comments

@aomarks
Copy link
Member

aomarks commented Feb 3, 2022

No description provided.

@aomarks aomarks self-assigned this Feb 3, 2022
@aomarks aomarks moved this from 🔥 Front Burner to 📋 Triaged in Lit Project Board Jun 10, 2022
@aomarks aomarks removed their assignment Jun 10, 2022
@augustjk augustjk changed the title [11ty] Support passing data as properties [labs/eleventy-plugin-lit] Support passing data as properties Oct 13, 2022
@cdata
Copy link
Contributor

cdata commented Dec 20, 2023

This is possibly better suited to its own issue, but: what about giving the components access to the 11ty data cascade? Is that already supported, or else would you consider it covered by the scope of this issue?

@cdata
Copy link
Contributor

cdata commented Dec 20, 2023

Since posting this, I have managed to pipe 11ty data into a Lit component such that the plugin can render a static template.

@bennypowers
Copy link
Collaborator

@cdata got code you can show us? cc @zeroedin

@cdata
Copy link
Contributor

cdata commented Jan 29, 2024

@bennypowers for passing 11ty data into components? I followed the recommenation the docs. At template render time, I serialized data to JSON and set it as an attribute value, for example with Nunjucks:

<my-component prop="{{data.foobar | dump}}"></my-component>

It's more of a pattern than an implementation. And, it comes with a caveat that every component that uses it has a gigantic JSON value in its attributes. This balloons the size of the generated output really quickly unless you are careful about what data you pass into components.

I should be clear and say that my original thought ("what about giving the components access to the 11ty data cascade") is not the same as what I'm describing here. If components had access to the data cascade, it would be like there is a singleton model in global scope that every component could read from at any time (whether configured as properties / attributes or not). It's unhygienic / yucky but it's coherent with all the other template strategies under 11ty.

@bennypowers
Copy link
Collaborator

@cdata do I understand you correctly: that if an existing component takes scalar attributes, that you can of them directly, but if serializable objects are passed to components that otherwise do not accept them, a wrapper component is required?

In other words, there is currently no way to pass "dot-syntax" properties to components that don't internally implement some special json-parsing logic, or some equivalent?

@cdata
Copy link
Contributor

cdata commented Jan 29, 2024

@bennypowers I don't know if I understand your question correctly. But, you can certainly modify the data in your template language before passing it in so that it is formatted the way the component expects. I do this to some extent and do not need any wrappers just to pass data as expected.

The constraint is that the data must be serialized to JSON and passed as an attribute value. Most Lit components can handle this, but not all web components (but then, I don't think the static rendering even works for vanilla WCs).

A lot of the data I'm working with is lists of non-trivial models - anyone using 11ty collections is probably in a similar boat - and this results in a lot of large attribute values, even if you format the data to look the way you want it to.

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

3 participants