hex-digital / lucidity-next-sanity-starter

WIP - Lucidity - The Enterprise-Ready Next.js 15 + SanityCMS Starter Template
MIT License
3 stars 3 forks source link

Decide on UI library approach #47

Open Jamiewarb opened 1 month ago

Jamiewarb commented 1 month ago

Do we want to roll our own UI library? Probably not, at least not for v1. There are already people doing excellent work on this.

So then we have two options:

E.G. if we have a Navbar from shadcn and another from ReactPrime, how can we best support them both, and allow the end user to choose the library they want to use? Is this practical?

Perhaps this is a later extension, if it is deemed necessary and popular.

For now, what is a widespread, accessible UI library?

Possibilities include:

There is also MUI but I feel it is too opinionated to be a contender I think it's the same for Tailwind UI. Things built with it are easily recognisable. I'd like to stay extensible—apps built with Lucidity should not look the same.

Jamiewarb commented 1 month ago

I'm thinking React Aria will be a good choice

I feel this is a good balance between usability and design. React Aria will provide us with accessible components that work really nicely, and a solid base for other's to either use the components we build, add NextUI on top of if they wish, or build their own. This allows for wider use and more differentiation in design

liamb13 commented 4 weeks ago

+1 on React Aria. Personally prefer shadcn and the likes for quick proof of concepts.

Jamiewarb commented 4 weeks ago

I think shadcn is nice but it comes with styles out of the box. The nav bar from Radix and shadcn is also a bit clunky and slow.

We did use shadcn for the Too Good To Go site and it worked out well there, and there is v0 that could be useful for quick modular content blocks.

Just wanted to make sure we're fully supporting WCAG 2.2 AA, which makes me lean towards React Aria. NextUI can also be added on top of that if people require more styled UI out of the box.

Still in two minds on this, what do you think?

liamb13 commented 3 weeks ago

React Aria for the inner modules (or even just individual field types?) Leave shadcn or any other library for the outer sections?

V0 continues improving, but I find it's usually easier to let it use plain text and replace them with field values after anyway.

Not exactly sure how that might work, but decoupling the inner field logic from the section design could be a nice approach. Keeping it flexible at the design level while ensuring it's accessible where it matters?

Jamiewarb commented 3 weeks ago

I'm not 100% sure yet. I'm not certain I'll even add modular content blocks to this starter—perhaps save that for a separate repo, so that we don't even need to tie it to a specific UI framework.

The only exception here is that I'd like to create a Header, Footer, Announcement Bar, Article Page and list of Articles page UI out of the box (but very bare bones). It would be nice if the Header was fully accessible. Again, not sure if that should be a separate package so people can drop it in after forking this one, so that we don't end up making that choice for them.

I think it's one to play around with when we get there to make that decision.

I don't think we'd want both React Aria and Shadcn—it would need to be one or the other, but if we can avoid both in this repo that could be the best option.

liamb13 commented 3 weeks ago

I almost wonder if it'd be easier to switch it out, rather than plug it in?

90% of the time, those components are identical with influence from global styling anyway.

Obviously just speaking from my own experience, but there's rarely a time I'm not using a header with a logo, menu and some form of a hamburger.

Could be a neat way to show the mindset of how to use the starter too. I feel there's a gap in the market for that in-between.

A lot of starters are either overly bare or just an all in one solution.

I imagine a lot of forks will evolve into their own internal versions of a starter. Having that guiding hand from the first fork might be nice?

liamb13 commented 3 weeks ago

Went a little all over the place in the last one, but I think use packages for functionality that likely needs to change or update over time. For things like headers/footers that users may want to tweak and change, could be nice to keep that in the starters app file structure.

Jamiewarb commented 3 weeks ago

Yeah, just want to try and find a way to provide that functionality out of the box but without prescribing it.

I don't want users who want to use Shadcn to have to remove the headers and footers, remove the React Aria package, remove any styling etc that we've done, to get to a baseline.

It might be nicer to do like pnpm lucid setup react-aria or pnpm lucid setup shadcn for instance, and get that stuff added in (just as a rough example of what I mean—a CLI would likely be further down the line, but something to aspire to. Could just be pnpm lucid setup and you choose your options, for example)

Jamiewarb commented 3 weeks ago

Could also take a branch approach. main has our base work, then there's a shadcn branch and a react aria branch, that have headers/footers and other UI implemented out of the box, so end user's can choose their flavour.

Jamiewarb commented 3 weeks ago

Liam mentioned a Figma file: here's a nice one by cal.com as inspo: https://www.bestdesignsystems.com/cal-ds