On the previous discussions there was a decision that utility function related to any of Paragon components can be added to the Paragon repo.
Notes:
Some util functions are generic / not really related to Paragon design system itself. In these cases, the util functions should likely live in @edx/frontend-platform/utils.
Is the util function specific to design system? If, yes, include in Paragon.
Form Validation functions?
Vlad to share out in FWG Slack to solicit more feedback / additional util function ideas.
Brian/Adam to work together to get the “what’s left” cheatsheet over the line.
[Jeff] is there a story to help with CSS translations
[Adam] tokens in theory we could extend the tokens framework to transform json tokens into whatever CSS properties we need, but it outside of the core paragon (this is more of a 2U/edX issue right now).
We have already planned our way out of using Bootstrap to support runtime theming more broadly
Having more than 1 LMS will always have inconsistency in the UI
Maintainability across 2U systems
Most DS’s don’t have the level of feature support that ours does today (ie DataTable)
General consensus from this group is that Paragon is still the right thing to use because we would be reinventing the same solutions we’ve already created, even if we buy the most robust new design system/component library
We have some heavy duty customizations in components today, and consider web components in rearchitecting, wrapping react components into web components
Adobe spectrum system
Tailwind vs Bootstrap theyre very different from eachother
tailwind.config.js to modify values vs. Bootstra' SCSS variable overrides
Design tokens could possibly generate tailwind.config.js.
Should there be a Product Management / business voice in this conversation?
We can’t make a decision about this within 2U/edX in a vacuum; Open edX likely would remain on Paragon if 2U/edX decided to move against it (which would still introduce brand inconsistencies).