Netflix / x-element

A dead simple starting point for custom elements.
Apache License 2.0
29 stars 12 forks source link

Discussion: Should default template engine allow literal property binding. #203

Open theengineear opened 6 days ago

theengineear commented 6 days ago

I think I’ve only ever seen a literal property binding by mistake, so I’m tempted to keep this strict. However, I wanted to farm for dissent a little bit. Currently…

NOT OK

html`<div .foo="bar"></div>`;

OK

html`<div foo="bar"></div>`;

or…

html`<div foo="${'bar'}"></div>`;

^^ But this last one is considered an anti-pattern and should not be used.

theengineear commented 6 days ago

IMO, we should not allow .foo="bar" — this binding can be expressed within the html syntax. And, if it’s really needed (e.g., the custom element doesn’t do attribute syncing), you can use .foo="${'bar'}" as a last resort.

theengineear commented 6 days ago

🤔 — I actually think we should do what we’re currently doing… just totally ignore that. You can do this today:

document.body.innerHTML = `
  <div .foo="bar">
    I have an attribute named dot-foo with a value bar!
  </div>
`;

I want to try very hard not to mess with default behavior… I wonder if that means we ought to actually not fail in the case of:

html`<div .foo="bar" .another="${whatever}"></div>`;

… not totally sure what the “best” choice here is!

theengineear commented 6 days ago

OK, one more thought, then I’m done commenting here 😸

I think we actually want to purposefully ignore this. I.e., expect that folks might put a . in front of attributes. The spec allows for it!

In other words — we can be fussy about the naming conventions that we accept for binding, but we should not be fussy about other bits of the html not used for binding. I.e., we should stay in our lane a bit more here, I think.