Replies: 1 comment
-
@keithamus thanks for taking the time to share your thoughts here. To be honest, I could go either way. I do think that the existing term we have for the feature (Content Areas) is sufficient as it stands. We chose Slots for the new implementation of the feature due to the term being used not just by the Slot element in HTML, but also in Vue. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Slots looks like a great addition to the API, and it extends
content_with
in impactful ways which make the whole API a lot easier to work with.I understand that the naming of the API was directly inspired by the
Slot
element in HTML. I think this is well motivated, from what I've seen they share many of the same conceptual behaviours and so it stands to reason they are named similarly.My concern, however, is that by co-opting the
Slots
name it may cause confusion as not all semantics match up with the HTML concepts. For example in HTML,<slot>
is only effective inside ShadowRoots, but the ViewComponent model ofSlots
does not modelShadowRoots
(nor should it). I can imagine a developer assuming that because these concepts match in name, they match in semantics, and this may cause a developer to trip up when the discover the semantics aren't shared.Does it warrant changing the name, to avoid too much mental coupling of the two concepts?
Beta Was this translation helpful? Give feedback.
All reactions