installation experience is too monolithic

[airtonix]

I like the idea.

However it feels like I'm installing a black box that uses prop driven customisation.

Installing into my tanstack/start monorepo app (where my ds is a separate pacakage), required me to install a huge amount of things i'll never use directly in my app

yarn add @hcaptcha/react-hcaptcha @hookform/resolvers @instantdb/react \
  @marsidev/react-turnstile @radix-ui/react-checkbox @radix-ui/react-checkbox \
@radix-ui/react-context @radix-ui/react-dialog @radix-ui/react-dropdown-menu \
@radix-ui/react-label @radix-ui/react-primitive @radix-ui/react-primitive \
@radix-ui/react-select @radix-ui/react-separator @radix-ui/react-slot \
@radix-ui/react-tabs @radix-ui/react-use-callback-ref @radix-ui/react-use-layout-effect \
@react-email/components @tanstack/query-core @tanstack/router-core @triplit/client \
@triplit/react @wojtekmaj/react-recaptcha-v3 better-auth class-variance-authority \
input-otp lucide-react react-google-recaptcha react-qr-code sonner tailwind-merge \
tailwindcss ua-parser-js zod  @better-fetch/fetch @radix-ui/react-avatar 

I can't help but feel that if this repo were refactored into a shadcn registry, then we can pick and choose the parts we need.

for example:

• tailwind-variants is superior to class-variance-authority
• i dont need triplit.. not even sure what it is.
• i don't need instantdb

I imagine a lot of other people have different requirements, but you get the idea.

[daveycodez]

I hear you, and releasing all the shadcn/ui components as pick and choose components is totally something that I've been planning, however...

This project was designed to provide all the features of Better Auth that you could want with as little time & effort as possible. If it was just copy/paste shadcn/ui components, it would take hours to pick and choose and customize everything to your liking, and then you'd have to write a ton of custom logic for all the different features. I get that some people prefer it this way, but for my purposes, being able to easily enable features just by adding a prop is way less work for each project and much faster to get off the ground, for minimal cost (installing a small package you might not use). You also get the benefit of being able to update the npm package to get the latest features, instead of manually updating & managing custom shadcn/ui components.

As far as tailwind-variants vs class-variance-authority, I don't have an opinion there. I use class-variance-authority simply because the official shadcn/ui Button and Alert components import it.

It's possible that I move the Triplit, InstantDB & TanStack options out to separate packages, but for now it's just easier to use those data providers this way. I'll think about this in the next few patches.

Regardless, if you check the Roadmap, shadcn/ui registry is currently next in line after Polar / Stripe integrations. It will take some time, but it's coming. It won't be as full featured as the npm package by definition, but you will be able to copy and paste whatever UI components you want to use. The npm package will use the shadcn/ui registry components and bundle them with the installation for devs who prefer ease of use.

[daveycodez]

For example, if you use the shadcn/ui components there will no longer be an AuthUIProvider, and you also won't be able to get the benefits of using automatic routing for your /auth paths and views. You'll have to manually import each form for each page.

Wheres with the npm package, you'll literally just be able to write the prop "organization" on the AuthUIProvider and it will automagically add all the organization cards to your settings page, and create the organization page for managing the active organization card, inviting members, accepting invitations, etc

[daveycodez]

Another big consideration is localization. Every component will have to define its localization separately, yet some components share localization strings, so it could become a bit messy managing all of this manually with shadcn components.

[AaronLayton]

I came here looking for this exact conversation 😁

I think the library is great up to yet, amazing work @daveycodez . I have implemented it on a project and it does exactly what you said it does, minimal configuration and allowed me to get everything setup simply and easily.

After playing around with it a while I did find myself asking the same question as @airtonix though and was wondering if there was more composable components that expose better-ui in a declarative way. I also spotted slight customisations that better-auth-ui do that is not part of the base shadcn/ui (for example card titles have custom font sizing). However, I appreciate this library was created before shadcn became popular, so even it being this far and closely matching is great.

I've not thought too much into what that could look like, so off the top of my head something like

<SigninOptions className="flex flex-col gap-3>
    <SigninOptionsProviders
        render={(provider => (
            <SigninButton asChild>
                <Button variant="outline" size="sm">
                    {provider.icon} {provider.name}
                </Button>
            </SigninButton>
        )}
    />
    <Button variant="outline" size="sm">
        My custom button injected
    </Button>
</SigninOptions>

I think you should keep your components as they are for easy implementation, but expose something like this for folks who really want to customise to the experience whilst still getting all the benefits.

[zbeyens]

I agree coupling shadcn components with a backend (better-auth) is not an easy task. However, I'd love to use the UI without the package. Even without individual components, a template built with shadcn/ui + better-auth would be good enough.

[daveycodez]

I'm planning on migrating everything over to shadcn registry at some point when it is no longer canary only