4 Matching Annotations
- Sep 2020
I can't add special props and keywords to every single component I have and will ever create for this to work.
Explicitly exposing any attributes that might get overridden by a parent seems impractical to me.
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
- forced to fork/copy and paste library code because it didn't provide enough customizability/extensibility / didn't foresee some specific prop/behavior that needed to be overridable/configurable (explicit interface)
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- forking to add a desired missing feature/change
- Svelte: how to affect child component styles
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
- being explicit
- maintenance burden
- explicit interfaces
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time