Staying away of slots is one of the methods and this strategy your present do make sense at the end of the day. I'm just asking if here, in custom-help-text, isn't it enough to only expose a property rather than a whole slot?
I guess it a philosophical question here and how well we trust consumers to have common sense or enough knowledge on how not to break semantics etc'.
Even here, there are couple of small scale concepts that this allows for which a property would be less opportune. Those includes application and customization of an icon in the Help Text content, the ability to link to additional information about the requested content or the surfaced error directly in the Help Text, and the ability to surface tooltip like overlays with locally available information about the Help Text also becomes available. Using properties, this could easily become an overly complex system of properties, or require a render prop, which while powerful involves a higher level of investment of the part of your consumers into the technological choices that you've made in building your element.
Beyond that, there's a less immediate, and more nuanced, list of capabilities that working in HTML directly surface that revolve around the immediacy and flexibility of content during the moments in an application lifecycle when JS cannot be guaranteed, but that's a whole other blog post!
In the end, it's very much NOT a question of "right" and "wrong" as much as a question of what "works". Either of these patterns work great at various things, and, when the goals of a project align with them, it's worth investing in them.
I agree, it's not a matter of right / wrong. just a matter of objective, where I see as consolidate a look and feel.
really curious how it feels in a large scale organization - do you find the "liberal" approach used appropriately by the consuming teams? do they follow design guidelines? do their designers follow design system guidelines as expected?
No less tricky, for sure. Namely the products are staffed with super capable people (designers and devs, both) and if they don't find the ability to do something in the Design System/Component Library, they're likely to build it themselves. For all the things that might get applied incorrectly with a liberal API, it's many times more when people are building things from scratch multiple times throughout a company. When they're working from our elements we at least have a finger on the scales, as it were.
With most approaches, I think the possibility of making mistakes runs much higher than we'd like to pretend. One thing we're looking into to reduce this possibility is a dev build of our components, leveraging the exports map in package.json, similar to what Lit has been doing in this area. The hope is for it to be a bit like linting on steroids, and when we finally get something together on this, don't doubt that we'll be sharing out our findings.
Staying away of slots is one of the methods and this strategy your present do make sense at the end of the day. I'm just asking if here, in
custom-help-text, isn't it enough to only expose a property rather than a whole slot?I guess it a philosophical question here and how well we trust consumers to have common sense or enough knowledge on how not to break semantics etc'.
In this base version, you might be right.
Even here, there are couple of small scale concepts that this allows for which a property would be less opportune. Those includes application and customization of an icon in the Help Text content, the ability to link to additional information about the requested content or the surfaced error directly in the Help Text, and the ability to surface tooltip like overlays with locally available information about the Help Text also becomes available. Using properties, this could easily become an overly complex system of properties, or require a render prop, which while powerful involves a higher level of investment of the part of your consumers into the technological choices that you've made in building your element.
Beyond that, there's a less immediate, and more nuanced, list of capabilities that working in HTML directly surface that revolve around the immediacy and flexibility of content during the moments in an application lifecycle when JS cannot be guaranteed, but that's a whole other blog post!
In the end, it's very much NOT a question of "right" and "wrong" as much as a question of what "works". Either of these patterns work great at various things, and, when the goals of a project align with them, it's worth investing in them.
I agree, it's not a matter of right / wrong. just a matter of objective, where I see as consolidate a look and feel.
really curious how it feels in a large scale organization - do you find the "liberal" approach used appropriately by the consuming teams? do they follow design guidelines? do their designers follow design system guidelines as expected?
No less tricky, for sure. Namely the products are staffed with super capable people (designers and devs, both) and if they don't find the ability to do something in the Design System/Component Library, they're likely to build it themselves. For all the things that might get applied incorrectly with a liberal API, it's many times more when people are building things from scratch multiple times throughout a company. When they're working from our elements we at least have a finger on the scales, as it were.
With most approaches, I think the possibility of making mistakes runs much higher than we'd like to pretend. One thing we're looking into to reduce this possibility is a dev build of our components, leveraging the exports map in
package.json, similar to what Lit has been doing in this area. The hope is for it to be a bit like linting on steroids, and when we finally get something together on this, don't doubt that we'll be sharing out our findings.nicee, were refactoring our own lib to a single repo and that's exactly what we're doing as well
Thanks for sharing all this, looking forward to see what you'll come up with...