4 ms·

<editable-list title="TODO" list-item-0="First item on the list" list-item-1="Second item on the list" list-item-2="Third item o

<editable-list title="TODO" list-item-0="First item on the list" list-item-1="Second item on the list" list-item-2="Third item on the list" list-item-3="Fourth item on the list" list-item-4="Fifth item on the list" listItem="This will not appear" add-item-text="Add new list item:" > </editable-list> You could easily do this a different way, if you still wanted it to be an attribute <editable-list items='["first", "second"]'> and pass json to a single attribute. Or make child <list-item>'s. One thing about web components though, having shipped web components for an internal design system, is that a lot of people don't understand the difference between html attributes and the properties of the underlying javascript objects. In plain HTML, or most server rendered templates afaik, there's no way to pass non-string data declaratively like you could with say Vue where you can choose property vs attribute to bind data.

rglover 3y ago
> You could easily do this a different way Yes, but that you have to make a choice means the design is poor. That's why stuff like React (imo) is a failure: there's a kajillion ways to do the same thing which end up creating dogma and sloppy/inconsistent code (read: bugs). Web Components—as far as I've seen—are making the same mistakes, but even worse, as a standard. As a web standard, Web Components should have been more carefully crafted. There's zero reason the spec couldn't have allowed me to wrap a normal <li> tag in the example above. That it doesn't means, somewhere along the road, a compromise was made that shouldn't have been made. The problem with all of that is when you introduce new web developers (who start by learning vanilla HTML, CSS, and JavaScript), as soon as they get to wanting to build more complex stuff (read: components), they essentially have to "unlearn" much of what they learned. Why does that matter? Paraphrasing Uncle Bob: because the rate of new developers doubles roughly every five years, that means half the programmers in the world have < 5 years experience. If they're learning bad/inconsistent patterns from day one, that means the quality of the software they build (and God help us, the tools they create later) is on a permanent downward slope.
- spankalee 3y ago
  You could do the same weird attributes thing with props in React. Does that make React's design equally poor? I don't know how you can prevent bad component designs like this.
  - rglover 3y ago
    https://github.com/cheatcode/joystick#writing-a-component https://github.com/cheatcode/joystick#writing-a-component
    - spankalee 3y ago
      const EditableList = ui.component({ render: ({ props }) => { return ` <ul> ${each(Object.keys(props).filter((p) => p.startsWith('list-item-')), (p) => `<li>${props[p]}</li>` )} </ul> `; }, }); // Usage: ${component(EditableList, { ['list-item-0']: 'First item on the list', ['list-item-1']: 'Second item on the list', ['list-item-2']: 'Third item on the list', ['list-item-3']: 'Fourth item on the list', ['list-item-4']: 'Fifth item on the list', })} edit: used each(), which doesn't change the point that you can make a bad component API in any framework.
      - rglover 3y ago
        https://github.com/cheatcode/joystick#each-and-e https://github.com/cheatcode/joystick#each-and-e
      - rglover 3y ago
        Re: your edit, that's not a bad component API, that's bad JavaScript (intentionally written by the author, in this case).
        spankalee 3y ago
        This is exactly my point. The MDN element is bad (the component has a bad API), and made bad by the component author, not the web components APIs.

rglover 3y ago

> You could easily do this a different way Yes, but that you have to make a choice means the design is poor. That's why stuff like React (imo) is a failure: there's a kajillion ways to do the same thing which end up creating dogma and sloppy/inconsistent code (read: bugs). Web Components—as far as I've seen—are making the same mistakes, but even worse, as a standard. As a web standard, Web Components should have been more carefully crafted. There's zero reason the spec couldn't have allowed me to wrap a normal <li> tag in the example above. That it doesn't means, somewhere along the road, a compromise was made that shouldn't have been made. The problem with all of that is when you introduce new web developers (who start by learning vanilla HTML, CSS, and JavaScript), as soon as they get to wanting to build more complex stuff (read: components), they essentially have to "unlearn" much of what they learned. Why does that matter? Paraphrasing Uncle Bob: because the rate of new developers doubles roughly every five years, that means half the programmers in the world have < 5 years experience. If they're learning bad/inconsistent patterns from day one, that means the quality of the software they build (and God help us, the tools they create later) is on a permanent downward slope.

spankalee 3y ago
You could do the same weird attributes thing with props in React. Does that make React's design equally poor? I don't know how you can prevent bad component designs like this.
- rglover 3y ago
  https://github.com/cheatcode/joystick#writing-a-component https://github.com/cheatcode/joystick#writing-a-component
  - spankalee 3y ago
    const EditableList = ui.component({ render: ({ props }) => { return ` <ul> ${each(Object.keys(props).filter((p) => p.startsWith('list-item-')), (p) => `<li>${props[p]}</li>` )} </ul> `; }, }); // Usage: ${component(EditableList, { ['list-item-0']: 'First item on the list', ['list-item-1']: 'Second item on the list', ['list-item-2']: 'Third item on the list', ['list-item-3']: 'Fourth item on the list', ['list-item-4']: 'Fifth item on the list', })} edit: used each(), which doesn't change the point that you can make a bad component API in any framework.
    - rglover 3y ago
      https://github.com/cheatcode/joystick#each-and-e https://github.com/cheatcode/joystick#each-and-e
    - rglover 3y ago
      Re: your edit, that's not a bad component API, that's bad JavaScript (intentionally written by the author, in this case).
      - spankalee 3y ago
        This is exactly my point. The MDN element is bad (the component has a bad API), and made bad by the component author, not the web components APIs.