loading...

re: Case Study: Building a Component Library VIEW POST

FULL DISCUSSION
 

Hi Kathryn,

thanks a lot for the nice post!

As you were talking about how component libraries become unmaintained and that you import your components into your projects... I was wondering if there is no way that storybook and your projects use the same files? That way a component library would never be unmaintained as it always shows the actual components of your project.

Also, when you write about "zooming out"... You wrote that you use the atomic design principle. By following that you could also create templates in your component library which gives you the bigger picture, couldn't you? You wouldn't have to wait until the components are imported into your application then.

I was really curious about this post as I recently build my own component library application. So, not the components itself, but basically my own storybook (you can find it here).
What was important for me that I can import it into my project and that it then uses the actual component files, because in my opinion it's absolutely necessary to keep the component library up-to-date - and that it will never stay 100% up-to-date if your project and your component library don't share the same files.

When I work for clients we usually even go a step further and develop a whole dummy implementation of the website in our component library (usually patternlab - unfortunately I wasn't able to use my app with a client yet). That way the frontend can be developed completely independently from the backend. Later on, the backend developers take the files and do the integration. But I guess that's a different use case than what you have in your company.

Anyway, thanks again!

Michael

 

Alright, I want to make sure I answer all your questions, so let me know if I leave anything out, haha!

Re: using the same files – our use case is actually pretty similar to the one you describe at the end of your comment. We also have an application for our Component Library that includes the Storybook UI as well as the components themselves. This blog post describes an approach VERY similar to what we do. Currently, all our apps have the component library added in the same way you would add d3, lodash, or any other external library, so keeping them updated is as simple as running yarn upgrade 'component-library'.

Re: zooming out – in an ideal world, yes. But in a more practical sense, we already had 3 different applications with similar (but not exactly the same) UIs. Our hope was to start creating components that could unify the visual look, so our suite of applications actually felt like a suite – to try and get an "easy win" on this front, we opted to start replacing small components (like buttons, form inputs, etc) to start creating consistency. In doing this, we felt some chafing re: integration of new components into various existing UIs. I think a "pure" Atomic Design approach probably could have fixed this, but only if you were willing to do ALL the design upfront in the Component Library, and not start to implement any of it in actual applications until you had all of it figured out – we opted to start implementing small pieces and adjust as we went. In the long run, I still feel like this was the right move – it's a little bit more agile and iterative, and that fits how we tend to work as a company.

Hopefully this was helpful!

code of conduct - report abuse