className doesn't override existing Tailwind classes in Navbar component

[jackpalaia]

Describe the bug
When trying to give the Navbar component a bg-black Tailwind class via the className prop, nothing happens. The class is getting applied to the component, but the bg-black class is not overriding the exisiting bg-white class already on the component. This is unintuitive as classes supplied via className should change the styling of the component.

To Reproduce
Create a Navbar component with a className of bg-black: <Navbar className="bg-black">. The background color of the Navbar doesn't change to black as expected.

Screenshots

Project information:

• Tailwind: 3.2.4
• Flowbite: 1.6.3
• Flowbite React: 0.3.8
• Type: NextJS

[tulup-conner]

Hi there, you can either use a theme as described in the README to overwrite the Navbar theme and replace the background color class, or use !important via Tailwind CSS - !bg-X.

[DarrenRED]

Hi @tulup-conner

Whilst using !important via Tailwind does in fact work, it's a hack. I can't see a way to overwrite the Navbar theme in the docs. Here is the interface for the NavbarTheme..

export interface FlowbiteNavbarTheme {
    root: FlowbiteNavbarRootTheme;
    brand: FlowbiteNavbarBrandTheme;
    collapse: FlowbiteNavbarCollapseTheme;
    link: FlowbiteNavbarLinkTheme;
    toggle: FlowbiteNavbarToggleTheme;
}

None of the types associated with these properties reference anything to do with styling.

[rluders]

@DarrenRED take a look into this PR #800 and here: https://www.flowbite-react.com/docs/customize/theme

[tulup-conner]

@DarrenRED Hi there - you are indeed correct that !important is a hack and we have deliberately created a system to make it so you don't need to do that. You can learn about that at https://www.flowbite-react.com/docs/customize/theme - the docs have improved considerably, especially on this subject, since February.

In short, we redirected all of the Tailwind CSS classes applied to each Flowbite React component into the theme whose TS typing you printed in your comment. That means you can pass a custom theme to replace Tailwind CSS classes, using a theme={} prop, rather than using !important in a manual className override.

[DarrenRED]

Hi @tulup-conner, yes since writing my last comment I've worked out how to leverage the theme prop effectively, however this was achieved largely via trial and error and clicking through type declaration files.

For example..

export interface FlowbiteTextInputTheme {
    base: string;
    addon: string;
    field: {
        base: string;
        icon: {
            base: string;
            svg: string;
        };
        rightIcon: {
            base: string;
            svg: string;
        };
        input: {
            base: string;
            sizes: TextInputSizes;
            colors: TextInputColors;
            withIcon: FlowbiteBoolean;
            withRightIcon: FlowbiteBoolean;
            withAddon: FlowbiteBoolean;
            withShadow: FlowbiteBoolean;
        };
    };
}

Turns out to modify the actual classes of the <input> tag that is rendered by a <TextInput /> you need to access the field.input.base property. The base property is integral to how the theme prop works but is not mentioned in the documentation at all. Additionally, other CSS properties other than the classes I added seemed to be effected by me changing the base property. Noticeably the width, but could be others. I haven't investigated it fully but adding classes appears to have unintended side effects.

I think it'd be good to document the theme prop in full to avoid others frustration in the future. There are still some undocumented props in the above example that I do not know what they do, that may be useful. E.g. addon - how is this different to base? That may be good to know.

Our team purchased Flowbite to bang out a project with speed in mind and I've spent quite a lot of time banging my head against simple CSS issues and I think this is really just a documentation issue.

[tulup-conner]

Yep, we are well aware it is a documentation issue and are actively trying to solve it. All the frustrations you have had are the same ones I and everyone else using the software has run into at some point. Design systems are complicated :)

Unfortunately, there isn't a simple and straightforward way to systemically document the purpose of each theme key, but we're brainstorming #808