feat: Customizable UI components

[travis]

I've introduced a new package called react-ui that uses the headless components to build higher level components with some markup and styling. The markup is not customizable, but @cmunns has been proving out how we can make the styling customizable using CSS variables in #140

react-ui has 3 components that simply wrap the underlying react-{keyring|uploader|uploads-list} packages and one that brings them all together into a component that developers should be able to simply drop into their applications and start uploading files. I'm conflicted on whether we should merge this now and iterate on main or separate the headless UI components into their own PR and merge react-ui later once we've figured out the CSS variable story - looking for feedback!

[olizilla]

We need to resolve the conversation from #136 (review) included here to make it easier to follow:

Can we split the react-ui stuff into a separate PR? I think it's a good idea to provide these components...but I'm just not 100% on the name "react-ui"...it sounds too general. I think it'll just become a pile of unrelated components rather than a focused set. Perhaps they could just be exported from the existing packages under /ui e.g. @w3ui/react-uploader/ui or just as another export import { UI } from '@w3ui/react-uploader' && <UI.SimpleUploader />?
– @alanshaw (source)

Yep I considered this but

a) then there's no clear place for the "dropin" component to live
b) people who just want to use the Headless components get all the deps required for the Customizable components (tree shaking should make this not a big deal for many users, but still not really ideal)
c) I have a soft preference for sticking to one level of abstraction per package (ie, it feels like a slightly better developer experience to know that all of the components in the Headless packages follow the Headless conventions)

One solution that would solve all of these is to introduce@w3ui/{uploader,uploads-list,keyring}-ui packages or something similar, but that feels like an explosion of packages once we apply the pattern to Vue and Solid as well...
– @travis (source)

no doubt I will retred old ground here; bare with me i need to arrange my thoughts!

tanstack was the inspiration for the existing packages. The terminology used there is headless vs component based libraries. https://tanstack.com/table/v8/docs/guide/introduction#component-based-libraries-vs-headless-libraries

tanstack implements UI agnostic "core" libs and adapters that map the core state handling logic to each ui libraries preferred way... e.g @tanstack/react-table provides react hooks.

tanstack deliberately avoids offering components that provide markup, so we are adding another dimension to our offering with our customisable components and headless ones... it's good, but we have to take care when explaining it.

I understand that https://github.com/tailwindlabs/headlessui is an inspiration for the react-ui proposed here, which produces some DOM, but aims to make them customisable with tailwind patterns.

I note that we're likely to end up with top level packages for the headless implementations, and then the same again as a tree of components nested under packages/react-ui, but as @travis notes it does let us add compound components like the drop-flavour to that package without forcing us to add a new package for everything. We should review this once we've done a couple of iterations on w3console and see if we are happy with it.

To nudge this forwards I suggest we proceed with @travis's layout with minor tweaks to the naming:

• packages/react-ui -> packages/react in the source tree
• @w3ui/react-ui becomes @w3ui/react in the package name
• drop the Simple prefix from the customisable component names
• (minor) examples/react/ui -> examples/react/playground per headlessui or guide per proposal: consolidate example apps #256

and we can (maybe, later) re-export all the headless react components from @w3ui/react/index so that developers who want the easiest DX can import anything from @w3ui/react... while others who don't trust the tree-shake and just want the bare minimum can install the relevant headless package directly.

I lean towards landing this sooner rather than later with those minimal changes and see how it goes. We'll iterate on the react experience on main until we're happy with it, and then port the decisions to the other UI lib implementations.

[travis]

+1 to all these suggestions, would love to get them landed asap!