We have a number of web component teams so it’s helpful to differentiate by tag prefix so that we know what team produced the component. We also support a prefix in front of design system components to allow for multiple versions to be used on the same page if needed (to be avoided if possible).

Hey hey 👋

This is a great take

Accessible design is the best design for everyone regardless of what decisions the government makes.

We have some level of visual regression tests for each of our components and are trying to improve coverage. Sometimes those types of tests are better at catching issues than standard unit tests for non functional components (ex. Tile, divider, etc)

If one exists or we are able to achieve it, I was thinking we could reuse our test suite to validate the react component look and feel/functionality

Yeah we haven’t invested the time but I’ve been thinking we could modify the existing wrapper generator to create the examples but my concern is the bad react code you mentioned.

Just curious, Konnor, if you were to do it over again, how might you do it differently?

Totally with you but it takes a while for teams to upgrade to react 19 and we’ve been supporting the wrappers for a bit now. We have great web component docs but very little when it comes to react and teams have noticed so I’m trying to find the quickest path to a solution.

So true about execs liking grass roots initiatives! Those who handle design and code everyday see problems that may not always bubble up as an immediately funded project. After we stood up our innersourced system, our approach was praised by senior leadership and is still spoken about years later 😊

Thanks! Hope it helps anyone who might be on the fence

Any chance you could add me in there?

👋 weve been building our design system at T. Rowe Price using web components for the past few years. Would love an add!

I broke down our usage at UXDX23 youtu.be/fxPfNx2KUWM?...