saadeghi / daisyui

๐ŸŒผ ๐ŸŒผ ๐ŸŒผ ๐ŸŒผ ๐ŸŒผ โ€ƒThe most popular, free and open-source Tailwind CSS component library
https://daisyui.com
MIT License
34.13k stars 1.3k forks source link

bug: input-error definition is not there in the output csss #3269

Closed indcoder closed 1 week ago

indcoder commented 1 week ago

What version of daisyUI are you using?

v4.12.14

Which browsers are you seeing the problem on?

All browsers

Reproduction URL

https://github.com/HackerspaceMumbai/Visage

Describe your issue

I'm programmatically adding the input-error class to form controls failing validation

image

While the input-error is being added to the input element, its not getting styled because there is no input-error styling in the generated output css even though input-bordered, input-focus etc are there.

image image

I have tweaked my theme but I dont think this should cause the error color disappearing from the generated css output file

/* @type {import('tailwindcss').Config} / module.exports = { content: ["./*/.{razor,html}"], theme: { extend: {}, }, plugins: [require('daisyui')], daisyui: { themes: [

        {
            light: {
                ...require("daisyui/src/theming/themes")["light"],
                "primary": "facc15",
                "secondary": "003366",

            },

            dark: {
                ...require("daisyui/src/theming/themes")["dark"],
                "primary": "facc15",
                "secondary": "00bcd4"

            },

        },

    ], // false: only light + dark | true: all themes | array: specific themes like this ["light", "dark", "cupcake"]
    darkTheme: "false", // name of one of the included themes for dark mode
    base: true, // applies background color and foreground color for root element by default
    styled: true, // include daisyUI colors and design decisions for all components
    utils: true, // adds responsive and modifier utility classes
    prefix: "", // prefix for daisyUI classnames (components, modifiers and responsive class names. Not colors)
    logs: true, // Shows info about daisyUI version and used config in the console when building your CSS
    themeRoot: ":root", // The element that receives theme color CSS variables
}

}

github-actions[bot] commented 1 week ago

Thank you @indcoder for reporting issues. It helps daisyUI a lot ๐Ÿ’š
I'll be working on issues one by one. I will help with this one as soon as a I find a solution.
In the meantime providing more details and reproduction links would be helpful.

saadeghi commented 1 week ago

Where is input-error in your code?

indcoder commented 1 week ago

@saadeghi please check 1st picture of the issue ...I have circled it in the Dev Tool. The element has a class of input-error, but the generated CSs output file doesn't have a definition of input-error

saadeghi commented 1 week ago

I see your screenshot. Where did you use input-error in your source code?
Tailwind doesn't generate classnames from your output HTML which you see in devtools. It generates from your source code.

indcoder commented 1 week ago

I added it in my .razor file ...just like how I did with input input-bordered...as well as focus:input-primary....which work...and these definitions are present in the npx tailwindcss generated CSs output file...but input-error is not. Sent from mobile

On Sun, 10 Nov 2024, 03:38 Pouya Saadeghi, @.***> wrote:

I see your screenshot. Where did you use input-error in your source code? Tailwind doesn't generate classnames from your output HTML which you see in devtools. It generates from your source code.

โ€” Reply to this email directly, view it on GitHub https://github.com/saadeghi/daisyui/issues/3269#issuecomment-2466477838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQAQZHCNJFBO4ZPXBOKZKDZ72BVJAVCNFSM6AAAAABRPAXEI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWGQ3TOOBTHA . You are receiving this because you were mentioned.Message ID: @.***>

saadeghi commented 1 week ago

Where is this .razor file? I don't see any input-error in your repo.

indcoder commented 1 week ago

Its generated in a Utility Validation Class ....which injects input-error into the HTML/Blazor component if validation fails.

https://github.com/HackerspaceMumbai/Visage/blob/13d3d7ac18a9fd63f310770ed3d5753c8038a5dd/Visage.FrontEnd/Visage.FrontEnd.Shared/DaisyUIInputError.cs#L13

saadeghi commented 1 week ago

Your content config in tailwind.config.js is only addressing "./**/*.{razor,html}" (not .cs files)
https://github.com/HackerspaceMumbai/Visage/blob/13d3d7ac18a9fd63f310770ed3d5753c8038a5dd/Visage.FrontEnd/Visage.FrontEnd.Shared/tailwind.config.js#L3

If you want it to also find class names in DaisyUIInputError.cs, update that content.

Let me know if you have a question.

indcoder commented 1 week ago

Ok thank you., @saadeghi.

Also wanted to leave a bit of my learning on this:

Now I also experimented why it worked in the PoC but not here.....In the PoC, I had experimented by adding the input-error in the razor to see how it behaved in the browser and then added it to Utility class and removed it from the razor file.. In this project, I added it directly to the utility class, but since tailwind config was watching only my razor files...it did not pickup the input error......

But why it worked in the PoC after removing it from the razor? Well IMO, its an edge case..once you add it in the razor file, the generated output css will retain that definition even if the input-error is subsequently removed from the razor file.

image
saadeghi commented 1 week ago

In dev mode when you add class names to your files they will be added to the CSS file but when you delete them they are not being removed instantly.

I'm mot sure but I think the same happens with JS functions, etc. and the reason is, faster HMR. Apparently loading some unused code in dev mode costs less time than removing them.

If you restart the dev server, the removed class name is not there anymore.

In the end, you should never trust the output you see in dev mode since the priority in dev mode is speed while the priority in production mode is efficiency and performance. That's why when you run a Lighthouse test on dev mode you get an awful result. Because a lot of unoptimized, unused things are included.