Comment by eludwig
Sorry to pile on to the doom and gloom around this, but I have been at a bunch of companies that tried this and have never seen it work out well.
The problem is that building generalized, actually-in-the-real-world reusable UI components is really, really hard! Generalizing other people's use cases is very tricky without walking in their shoes.
Usually what happens is that a glorious, well-intentioned group within the company puts together a few very short-sighted, yet kind-of-good-looking components for a very specific use case and management sees it and says: "hey, why can't we use this in other projects?" The answer, of course, is that they weren't meant for that! They don't handle about 100 different things that would allow for expanded use in the company. One would need a dedicated team to make it so, which management really doesn't want to pay for.
Trust me, it only gets worse from there...
My advice is to build domain-specific LOB components for your business area and use a real 3rd-party solution for the underlying GUI lib. This actually has a chance of working out. Even doing this is way harder than it sounds lol.
I mean starting a component library by building your own from the ground up is an absurd thing to even attempt.
IMO the only really sane approach is to start with a facade around an existing library. This way you get your single interface and your consistent visual style, but you are free to swap out implementations as necessary.