The line between abuse of and flexibility in design guidelines is quite narrow and an important part of deciding what it is that we ship to our users. Are you finding good success with that? If so, awesome! I'd love to hear what sort of architectural decisions (outside of staying away from <slot>s) you've leveraging to make that so.
Working from the Spectrum design system, much of my work feels like it should/could be locked down. However, delivering to clients all across and outside of Adobe, I've found that part of continuing to raise adopting of the Spectrum Web Components library is allowing teams to achieve what they see, even if it doesn't yet, or possibly never will, have an official place in the design system. Helping consuming teams to have success as early and often within the design language, while giving a nod to not the design language being a living, breathing things ends up being a good amount of our work 😅
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.
The line between abuse of and flexibility in design guidelines is quite narrow and an important part of deciding what it is that we ship to our users. Are you finding good success with that? If so, awesome! I'd love to hear what sort of architectural decisions (outside of staying away from
<slot>s) you've leveraging to make that so.Working from the Spectrum design system, much of my work feels like it should/could be locked down. However, delivering to clients all across and outside of Adobe, I've found that part of continuing to raise adopting of the Spectrum Web Components library is allowing teams to achieve what they see, even if it doesn't yet, or possibly never will, have an official place in the design system. Helping consuming teams to have success as early and often within the design language, while giving a nod to not the design language being a living, breathing things ends up being a good amount of our work 😅
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...