AssistantProvider was imported statically by the root layout, so assistant-ui, the Lexical composer, the Markdown renderer and Mermaid were downloaded and evaluated on every page. The existing getAvailability gate only skipped rendering, and the disabled branch still imported the board widget, which pulls the whole conversation surface. An instance with the assistant switched off paid the full cost, and so did the login page. Measured on two production builds, /auth/login went from 42 chunks / 3.81MB including an 820KB assistant-ui chunk to 36 chunks / 2.40MB with none, and the board page from 55 / 5.35MB to 56 / 4.56MB with none. Adds getFeatureFlagsAsync as one source of truth for instance-level feature switches, exposed both to the root layout and through a small GET /api/features endpoint. Resolving the flag on the server is what makes this work: next/dynamic never references the heavy chunk when the feature is off, while enabled instances still server-render it, so there is no loading flash and no remount.
Create T3 App
This is a T3 Stack project bootstrapped with create-t3-app.
What's next? How do I make an app with this?
We try to keep this project as simple as possible, so you can start with just the scaffolding we set up for you, and add additional things later when they become necessary.
If you are not familiar with the different technologies used in this project, please refer to the respective docs. If you still are in the wind, please join our Discord and ask for help.
Learn More
To learn more about the T3 Stack, take a look at the following resources:
- Documentation
- Learn the T3 Stack — Check out these awesome tutorials
You can check out the create-t3-app GitHub repository — your feedback and contributions are welcome!
How do I deploy this?
Follow our deployment guides for Vercel and Docker for more information.