Creating a UI library is not for the faint of heart.
And that goes doubly so for creating a Livewire UI component library.
There are so many components you need to build. There are many factors you have to consider. And it just takes a long time to reach a stable state for a 1.0 release.
But that’s precisely what I ended up doing. And it ended with the keystone package in the ArtisanPack UI library.
Here’s how I built the ArtisanPack UI Livewire UI Components package.
Why I Needed to Build a Livewire UI Component Library
As I was building out the Digital Shopfront CMS, I initially used components from Tailgrids, then switched to FluxUI.
I really liked both libraries and thought I was doing well creating a dashboard and admin area for Digital Shopfront with them.
But then I looked at the licenses for both of them and saw that they were incompatible with what I was creating.
I didn’t want to set myself up for a headache down the road with licensing and all that, which, to be honest, is the only thing more frustrating than creating a whole new UI library. Since I wasn’t too far along yet, I decided to pivot and create my own open-source Livewire UI component library.
Thus, ArtisanPack UI was born.
Struggles with Getting Started
While I was enthusiastic about starting down this road, I struggled to get started.
I couldn’t figure out where to even begin. The wheels in my brain were spinning at full speed, but nothing of value was making its way to my code editor, let alone the browser.
I really liked what FluxUI was doing, but I obviously didn’t want just to copy what Caleb Porzio was doing. That was an absolute no-go. And despite my many attempts with JetBrains’ Junie, I just couldn’t get the right plan in place to create what I was looking to build.
I spent way too many hours just grinding my gears and getting absolutely nowhere.
Forking Mary UI to Start
Then I stumbled upon Mary UI, which, thankfully, is an open-source project.
This was a great starting point. It had a ton of components built out and was based on another open source project: Daisy UI.
There was so much to like about this package. Plus, again, it was open source.
Also, it was missing a few things I needed, which made it a great prospect to fork the package, truly make it my own, and separate it from Mary UI.
I went from down and out to back in the game in absolutely no time.
Making it My Own
Once I forked Mary UI and changed the code references to ArtisanPack UI, I got to work making it my own.
I started by making sure all the components were as accessible as possible. Then I started adding some of my personal touches.
I incorporated the Icons package into the component library. Then I worked on adding variants to buttons instead of always using the “btn-{variant}” class name.
I also added a vertical tabs option to the tabs component, a drag-and-drop system to the image library component, and a search option to the tags component.
While the backbone of Mary UI is definitely still there, I feel like I’ve done enough to make the Livewire UI Components package its own package.
What the Future Will Hold for the Livewire UI Component Package
The future for the Livewire UI Components package is wide open.
Now that version 1.0 is finally released, I can start planning what cool new features I want to add.
I want to add advanced theming capabilities and form components.
I wouldn’t mind making the card and stat components look a little more modern as well. And honestly, creating a native, modern data visualization suite isn’t out of the question either.
Plus, it’s an open-source package, so anyone is welcome to suggest what they think should be included.
Essentially, the future of the Livewire UI Components package is a blank canvas, and I can’t wait to see what gets built on it!
