Improve Use with React Server Components

[tulup-conner]

React Server Components are now the default for Next.js apps using Next.js 13, the latest major version. Flowbite React users running Next.js will find that, when they try to use Flowbite React components inside their Next.js 13 app, they receive errors. It isn't clear how to fix these errors.

We would like to change that by introducing support for React Server Components where possible. We have discussed this internally after receiving feedback from the community (#448, #795).

We would like to present to you all a few different options we think will make it so you can use Flowbite React in Next.js 13 apps without being immediately disrupted by errors that break your app!

Additionally, we ask you to provide any suggestions that are not listed here. We are still learning about React Server Components along with you, and the library was designed without this new pattern in mind. We might need to think "outside the box" to find the best solution.

Our priority is to make it so users do not have to change anything about their existing apps. While change is sometimes unavoidable, we want to use a solution where all you need to do as a user is upgrade flowbite-react in your package.json.

The Problem

Earlier this year, we made it so you can customize the Tailwind CSS classes that are applied to each HTML element of every Flowbite React component using what we call a theme (#500, #611). You can create a theme in a few ways.

We ship a default theme for every component, and then provide users the option to either pass a custom theme to one component via theme={..} attribute, or create one central theme for many components by wrapping their app in <Flowbite theme={..}>..</Flowbite>.

This makes it really easy to quickly make changes to Flowbite React components, many of which have several internal HTML elements that would not be possible to directly edit via className. For example, Accordion arrows can be customized by providing a theme and overriding accordion.title.arrow. Without this, you would need to copy-paste <Accordion.Arrow className=".." /> inside every <Accordion.Title>..</Accordion.Title>. This is just one of countless examples.

Right now, we use React Context to allow users to create a custom theme. However, React Context is not allowed in React Server Components, nor are any other React hooks like useState or useEffect.

That means every Flowbite React component is completely incompatible with React Server Components. Even components that don't have any useState must be declared React Client Components, like <Button /> or <Timeline>..</Timeline>. That doesn't make sense, makes the Next.js development experience worse overall, and has negative performance implications.

The Solutions

Require Next.js users to re-export Flowbite React as a React Client Component library

User @BanDroid provided their solution to this problem that already works.

Create a file in your Next.js app that looks like this:

"use client";

export * from "flowbite-react";

Then change any import { ... } from "flowbite-react" statements to import from your new custom file.

You might find that components with child components, like <Sidebar> and <Sidebar.Items>, throw an error still. In that case, user @nickjanssen provided their working solution which looks like this:

"use client";

import * as Flowbite from "flowbite-react";
export * from "flowbite-react";

const { Brand, Toggle, Collapse } = Flowbite.Navbar;
export { Brand as NavbarBrand, Toggle as NavbarToggle, Collapse as NavbarCollapse };

Benefits

• You can already use the above solution(s) in your existing Next.js apps, and we encourage you to do so!
• We don't need to invest any further time/effort into this problem

Drawbacks

• You would need to create a file in each of your Next.js apps, and re-export every child component you use
  • We could provide a file on our docs that you can download or paste into your app
• You would need to change every import { ... } from "flowbite-react" statement in your app to instead link to the custom file
  • This is trivial with search and replace, but still creates work for every user - not what we want!
  • This would also be frustrating if we find a solution that no longer requires the custom file, because then you would want to search-and-replace again to just import from flowbite-react
• Flowbite React would still be entirely React Client Components, which comes with all of the drawbacks mentioned in Next.js docs

Add "use client"; to every component in Flowbite React

The Next.js docs on React Server Components suggest that third-party libraries (like Flowbite React!) add "use client"; to the codebase so Next.js users can at least use Flowbite React without errors. We would need to at least add this to every file that uses React state or context, which is almost all of them!

Benefits

• Next.js users could use the library like they always have - no changes necessary!
• It would be less time-consuming to make the necessary changes to the library, compared to other solutions

Drawbacks

• Flowbite React will still be entirely React Client Components, which comes with all of the drawbacks mentioned in Next.js docs

Create a build command for Flowbite React to merge custom theme

The reason this is a problem at all for Flowbite React is that we are using React Context extensively where it isn't absolutely required. We could re-implement theme support to not use React Context at all.

We currently use Context to accept your custom theme in <Flowbite theme={{ theme: { ... } }}>..</Flowbite>. That's because Flowbite React is a third-party library you import, so we can't know where exactly your custom theme file is - for example, by adding import customTheme from ../my-theme.ts to each component.

We could change this behavior by creating a CLI command for you to run, like:

npx flowbite-react theme ./app/theme.ts

However, this idea is experimental and may not work. We would need to test whether or not it's possible to merge your custom theme with the default theme in this manner. It isn't guaranteed that this solution would work for all users.

Benefits

• We would be able to convert every Flowbite React component that doesn't otherwise require React Context or state into actual React Server Components out of the box!
• We would also be able to run tailwind-merge in the build command, which would probably measurably improve the performance of large apps with many Flowbite React components
  • Currently, twMerge runs in the user's browser in every Flowbite React component you use
• You wouldn't need to wrap your app in the <Flowbite>..</Flowbite> component anymore

Drawbacks

• You would need to run the build command each time you change your custom theme, which would significantly detract from the rapid development cycle you can normally enjoy with Tailwind CSS
  • We could probably run a process in the background, alongside your development server, to watch your theme file for changes, and automatically re-build
• You would probably want to add this build command to your development pipeline, for example, as a script in package.json
• We would need to invest significant development time into testing, releasing a beta, processing feedback, and ultimately releasing the finished product
• We won't know if this solution is possible or works for all users without investing time into testing

Read custom theme file path from Tailwind CSS config file

We could probably also avoid using React Context by allowing you to specify your custom theme file path in tailwind.config.XX. Tailwind CSS supports this in the client by using a function called resolveConfig.

For example, your tailwind.config.js might look like:

module.exports = {
  ..
  flowbite: {
    theme: 'my/custom/theme.ts',
  },
  ..
}

However, this idea is experimental and may not work. We would need to test whether or not it's possible to dynamically load the contents of your theme file. It isn't guaranteed that this solution would work for all users.

Benefits

• Using the Tailwind CSS configuration is more intuitive for users, since we are already using Tailwind CSS with Flowbite React
• We would be able to convert every Flowbite React component that doesn't otherwise require React Context or state into actual React Server Components out of the box!
• You wouldn't need to wrap your app in the <Flowbite>..</Flowbite> component anymore

Drawbacks

• There is no way to dynamically figure out the file extension you've chosen for your Tailwind CSS config, which can now be .js, .mjs, .cjs or .ts - so we would need to require tailwind.config.js
• We won't know if this solution is possible or works for all users without investing time into testing
• We would still need to run twMerge on each component in the client

This idea was presented by @rluders.

Yours!

We will monitor this discussion actively and update this main post as new ideas come in, so other users can also let us know what they think.

What we need from you

Please comment in this discussion to let us know which options you like, dislike, and why.

If you have an idea that you think might work, but you don't see it here - please let us know in this discussion!

[tulup-conner]

If you don't have any extra ideas to contribute, but you like the idea of creating a build command for Flowbite React to merge custom theme feel free to just give this comment a vote or thumbs up!

[rluders]

And if we "fake" a context? By that, I mean, we read the theme file path from tailwdincss.config.js, and use it to import the file to the application, then we have a function, that will act like a "context", but it is not a context, instead it will read the data from a global object/variable that will hold the theme object (with or without the user changes - by that I mean, already merged with the user overwrite) and then the remaining part of the code will be the same, but, not using the context, but useTheme() will in fact just access the globals.theme variable.

Not sure if I make my idea clear here. Let me try to explain with code:

// tailwind.config.js
module.exports = {
  content: ['./src/**/*.{html,js}'],
  theme: { ... },
  flowbite: {
    theme: 'my/custom/theme.ts',
  },
  plugins: [..., require('flowbite/plugin')],
}

// src/components/Flowbite/helpers.ts

const config = require('tailwindcss.config.js'); // can we get only the config.flowbite here?

// @TODO how to merge the custom theme with the default theme?

export const useTheme = () => {
  return config.flowbite.theme;
};

And then the remaining code would basically be the same for the components. I have no idea if it will work... this is just a very crazy idea. Not sure about the pros and cons 'cause I didn't test it and I have no idea if it will work as expected, but... it should at least remove the context from the components.

[tulup-conner]

I think this is a great idea well worth exploring

[rluders]

If someone is interested in pushing some PR with a PoC for this one to test the idea... just go ahead. TBH, I don't see how it will perform, but I can imagine that the refactoring impact will not be that huge, and for unit tests, everything should be working the same.

The solution also should not have any impact on the client rendering... at least, not that I can see right now.

[tulup-conner]

If you don't have any extra ideas to contribute, but you like the idea of requiring Next.js users to re-export Flowbite React as a React Client Component library feel free to just give this comment a vote or thumbs up!

[tulup-conner]

If you don't have any extra ideas to contribute, but you like the idea of adding "use client"; to every component in Flowbite React feel free to just give this comment a vote or thumbs up!

[MRezaSafari]

Hello :)

Im not really sure if it's a good suggestion or even if it works. but worth a shot :)

I can explain more if the idea is worth it.

[rluders]

@MRezaSafari it looks very similar to this idea. However, I'm not sure if moving the theme to the extends is a good thing, 'cause TailwindCSS may/will interpret it as something else. 🤔

[tulup-conner]

You can vote now in our first round of polling at #940 !

[pochka15]

Unfortunately I'm like I'm too dumb to understand the whole point of the discussion. Like once again, why can't we just export and import the theme object? Why do we need a context for this? I understand that client context cannot be shared with the server context but here we just have a super-simple singleton object theme which is not getting changed by client. So what am I missing here?

I also have a few questions. First is it's mentioned this sentence all of the drawbacks mentioned in Next.js docs. I still don't understand what meaningful drawbacks we are talking about. Is it about the thing that we'll always send serialized props from the server in order to render components in browser? Soo what 🤔 ?

Second is that @MRezaSafari 's suggestion is something what quickly came into my mind. This is just "do this way or that way" approach depending on whether it's a server or a client. But I didn't get the concern about tailwind. We can rather continue that discussion in already opened thread

[rluders]

Well, this is basically what I'm saying here. We would have a "singleton" that will return the theme object. Basically the useTheme() will just return the theme.ts object, and that is it, no context is needed.

The concern about Tailwind from @MRezaSafari's suggestion is that the extends object is used by the Tailwind itself to build the custom or to extend its classes, adding the theme isn't something that we should do... Not a good idea to mix up context. This is why in my suggestion I introduced a separate property for the flowbite-theme object.

[rluders]

Another impact that needs to be considered is how it would affect the dark/light theme switcher.

[rluders]

Folks,

Please test the 0.7.0-beta.2 release. It introduces some RSC support and improves the theme by converting it from Context to Singleton.

It shouldn't introduce any breaking change. If you find any issues, please, report them as an issue, and don't forget to say that you are using the beta version.

[rluders]

Yeah, I can totally see that. I think this is wrong. So, probably the beta.2 is broken. Let me see if I can place a fix for that.

[selimcumart]

Thanks! Keep it up (Y)

[rluders]

PR created. Just waiting till get merged to release a new beta. Thanks for testing and reporting the issue, @citom.
#1058

[SutuSebastian]

@SutuSebastian maybe some imports are wrong? AFAIK, we shouldn't be able to use ~ alias inside the library.

I need to dig why is that a problem after the build process.

[rluders]

https://www.npmjs.com/package/flowbite-react/v/0.7.0-beta.3