Open arkihillel opened 7 years ago
Hi @arkihillel, just wanted to thank you for the great comments. I'll follow up as quickly as my time allows.
Since this feedback covers a broad range of topics, each of which may take some discussion to resolve, I think I'll split most of these into separate issues.
I think the separately-filed issues cover everything except your top level comment:
A problem I have, though, is that the list doesn't differentiate between UI and functional components
That's a fair point, although I'm not sure how to address it. How would you imagine the checklist reflecting that difference?
Thanks you very much for the detailed response @JanMiksovsky
I'll be sure to properly answer each of the new issues in a short while
I've re-read the list for the tenth time, it's very useful
A problem I have, though, is that the list doesn't differentiate between UI and functional components
Otherwise, I have some feedback about the rules that are already present in the list:
A web component should appear self sufficient as far as the user is concerned. If resources are required, they should be packaged with the component. The distribution and packaging standards should be a matter of their own
This rule is not very clear. Does an overlay affect over elements?
This too is unclear. What's considered a wide range? The
<span>
tag only accepts a very limited set of child elements. Putting a<div>
as a child of a<span>
will somehow work but it's supposed to be invalid. If the HTML does not always allow child Independence, it shouldn't be considered standard for web components too.This rule will be practically impossible to enforce in some cases. Take the
<google-map>
Polymer element for example. While, in theory, it could support other services, it just wouldn't make sense to bundle them all under the same componentThis one is really tricky. While it is very important on visually large components like a text editor, it doesn't necessarily make sense on more atomic ones like buttons. The HTML is not responsive per spec, responsiveness is "only" a UX standard. Then, a more atomic element shouldn't deal with that
Long operations should only be allowed whenever the network is used (think API calls or lazy loading external resources). If an UI element does need computations in order to work, it should be coupled with an external, functional, element.
e.g. a Fibonacci calculator should be composed of two elements
<fib-view>
and<fib-calc>
. Each one should have its own set of events and the user should be in control of whether or not to show a loader and what this loader would look like. Then again, this concern may already be solved by letting the user customize the calculator loader stylingI may have misunderstood the intent of some of the rules, don't hesitate to correct me if I'm wrong.