Utilizing a library of components that are prebuilt and theme it for our own use

[glvangorp]

There are many libraries and frameworks that have already been prebuilt, tested, and optimized. The goal is to create a reusable collection of components and styles across the company. Why don't we leverage a set of components that has already been developed and then theme/style it to fit our needs? Reinventing the wheel and whatnot.

Type of change

Please select only 1.

• [ ] New Component
• [ ] Enhancement to existing component
• [ ] Substantial documentation change
• [x] Changes to the design or features of sparkdesignsystem.com

Change category

Select as many as apply.

• [x] Visual (Changes to the visual design of a component)
• [x] UX (Change the user experience design of a component)
• [x] Component (Modifying the functionality of a component)
• [x] Editorial (Changes to documentation or content style)
• [x] Code Style (Changes to the way code is written or the component architecture)
• [x] Accessibility (Substantial changes to a component's accessibility)

Rationale

Creating our own components from scratch costs a ton of money in development. Why not leverage something that has already been built and theme it to saves the company money and all the developers headaches?

https://www.webcomponents.org/libraries

Live Examples

https://www.polymer-project.org/ https://materializecss.com/sidenav.html https://vaadin.com/ etc...

[RCopeland]

Hey Greg, We talked through the idea of using a third-party lib a little bit before we started the project. Here's some of the reasons that we wanted to keep it in-house:

• We want explicit control over what components are included, and in what capacity
• We wanted to make our own decisions around a11y and user interaction
• We're wary of adopting too wholly into a particular framework, as the FE ones fall in and out of favor so frequently
• Not many of the existing frameworks supply enough functionality to cover all of Spark's use cases (QL, as well as FOC / Fintech, etc.)

Thanks for the input!

[glvangorp]

I think those bullets are all very much valid. I was thinking that spending time optimizing every component for every browser and building text inputs, buttons, dropdowns, etc from scratch could be mitigated. Pull in some of these web components as a base and then start from there. That allows us to maintain a specific set of components, control accessibility, and augment it with whatever components we need.

Also, we don't have to choose a specific framework because as you mentioned, front end frameworks change all the time. I was suggesting that we use just the basic js/html/css for basic interaction and have that solid base that could be used in any front end framework. Then building more complex component logic could be build into an Angular/React/etc component later. Building text input fields or a search bar doesn't depend on a specific framework.

I think we could cover all of those concerns with something like materializecss.com and then just theming it, adding accessibility (if it doesn't already exist), adding/removing components. Basically just use it as a starting point so we don't need to start from scratch

[RCopeland]

Ahh, I see what you mean. For the CSS, we are using a base framework, https://github.com/ScalesCSS/scalescss We get a lot of the css from there, which allows us to maintain control over our markup, and add styling css on top.

I'm hesitant to add any frameworks, such as materializecss, that include styling information of their own that we would need to override. I think if we themed anything beyond color or simple spacing, we'd still have to test in browsers / devices anyway. I'd wager that the theme developers working on materialcss (for example) themes are also testing across browsers.

I'd also be afraid of the outside css being more specific than we'd like, which would make it difficult to include into an existing application. As it is today, Spark is so non-specific, that it can largely be included as is into an existing app with no visual issue. This allows apps to adopt Spark in a piecemeal way, which fits better into the agile structure a lot of our teams are practicing.

When we were validating the approach, we also took a look what other design system teams were doing. A lot of the ones that we follow as inspiration are taking a similar approach. https://adele.uxpin.com/

I totally agree with you on the points about developing and testing homegrown components being expensive and time-consuming, for sure they are. However, I think the control and ease of integration we get in return make it worth it.

[glvangorp]

That's good to hear. What's going on with all those extremely verbose class names?

sprk-C-WideNavigation__link--some-other-stuff-child-1-b

I was attempting to pull in some components just as a POC and trying to get ahead on things and this feels very bloated in the markup. Trying to conditionally apply/remove these classes or alter them to say something like NarrowNavigation means we have to change every element and all the children to get the new styles. This just seemed like an interesting choice and was wondering what the rationale/discussions were about that?

[RCopeland]

I agree its pretty verbose. We're using a hybrid of several concepts: For example, take

.sprk-c-WideNavigation__link--active

The 'sprk' part is the library's namespace, we use it to absolutely avoid name collision with a site's existing css.

The 'c' is one of a few options, used to denote a components intended place in heirarchy:

• b: base
• c: component
• o: object
• u: utility

We do that so that at a glance you can tell how much styling information is implied in a class name.

The 'WideNavigation' part is the name thats unique to the component, the 'B' in BEM (Block, Element, Modifier) The '__link' denotes a piece or part of the larger component, the 'E' in BEM. The '--active' denotes a modified version of a Block, or Element, the 'M' in BEM.

We do that so that you can look at a class name and have a general idea as to what it means in terms of styling. For example, our intent is that you could look at:

sprk-c-Button sprk-u-Display--none

And be able to tell at a glance that a utility is hiding the button.

We documented a longer version of this out here: https://sparkdesignsystem.com/docs/class-naming-convention

Hope that helps : )