New Theme "daisyUI"

[keithnd6]

Hi everyone! We've been experimenting with adding more themes under the Tailwind umbrella.

The package already offers enough customizability to override most of the table rows and columns' CSS classes, but we wanted to go further. So, we added a whole new theme: "daisyUI". This is a component library built on top of Tailwind that uses semantic class names instead of core utility classes.

Why did we do this?

Beyond adding new themes for users, we noticed that maintaining CSS classes across Tailwind can become unwieldy.

Imagine a scenario where you need to change the background color for an active selected row. This would require the maintainer to search and replace that specific Tailwind color for the active selection, both for light and dark modes. While it's manageable when there aren't many instances, it can quickly become complex.

1. Example with Tailwind

<input class="block w-full border-gray-300 rounded-md shadow-sm transition duration-150 ease-in-out sm:text-sm sm:leading-5 dark:bg-gray-800 dark:text-white dark:border-gray-600 @if (isset($columnSearch[$field]) && strlen($columnSearch[$field])) rounded-none rounded-l-md focus:ring-0 focus:border-gray-300 @else focus:border-indigo-300 focus:ring focus:ring-indigo-200 focus:ring-opacity-50 rounded-md @endif" />

1. Example with daisyUI

<input class="input input-sm" />

I agree this example might be too simplistic, but take this example and consider the various components across the package and apply this same example to all those components, now it suddenly starts to not be as fun and simple 😅.

Advantages

1. Since daisyUI is built on top of tailwind, for anyone who already uses tailwind, they can simply switch to theme=”daisyui” and everything should still be fine with their default tailwind config.
2. daisyUI offers high customisability via their tailwind config options, what this means is, you can go as far as almost mimicking a Bootstrap theme 😄 by playing with the configs.
3. Maintainability, in a case where the developer needs to update any styling specific stuff the would only need to tinker with the config.
4. If for some reason there is a need to reset some style where you do not need daisyUI, you can simply use the tailwind utility classes either alone, or in conjunction with daisyUI.

Disadvantages

1. Well, like with any project, introducing new features or functionality may have undesired side effects. So there is still some work the needs to be done to fine comb the implementations and make sure they pass the tests via composer test .
2. Could we have missed something somewhere?
   1.Probably, the guide to adding a new theme in the package has been config('livewire-tables.theme') === 'tailwind’, $isTailwind and $component->isTailwind() these gave an indicator of where Tailwind was used and therefore helped in showing were we needed to add any daisyUI specific configurations.

Showcase

Here are some of the examples from when using the accompanying demo repo laravel-livewire-tables

We have implemented this into our project with success, we would like to know if we could create a pull request for this feature?

[lrljoe]

I think it's important to note that the reason Tailwind is so popular, particularly with this package, is the ability to over-ride the defaults with ease, for example, changing the background colour of a table cell, based on the value:

This example would change the background colour of the "Total" field/column, based on whether it's less than 501 (red), 501-999 (amber), or 1000+ (green)

public function configure(): void
{
 // Column is the "Total" Field, and the value of Total is Less Than or Equal to 500 - Set Background of Table Cell to Red
  $this->setTdAttributes(function(Column $column, $row, $columnIndex, $rowIndex) {
    if ($column->isField('total') && $row->total <= 500) {
      return [
        'class' => 'bg-red-500 text-white',
      ];
    }  // Column is the "Total" Field, and the value of Total is Between 501 and 999 - Set Background of Table Cell to Amber
    else if ($column->isField('total') && $row->total > 500 && $row->total < 1000) {
      return [
        'class' => 'bg-amber-500 text-white',
      ];
    }   // Column is the "Total" Field, and the value of  Total is 1000 or more - Set Background of Cell to Green
    else if ($column->isField('total') && $row->total >= 1000) {
      return [ 
        'class' => 'bg-green-500 text-white',
      ];
    }

    return [];
  });
}

Daisy under the hood simply uses tailwind's apply directive, and doesn't actually ADD anything.

The whole idea behind the level of customisation present, is that someone can choose precisely which classes to apply. A significant number of the elements now have options to override JUST the colours, or JUST the styling classes, meaning it's easier to adjust individual element colours, without worrying about breaking anything.

I'd understand completely if the package didn't allow for customisation of classes/attributes on almost every element!

My concern is - we'd add in a "daisy" theme (which would be a ton of Tailwind apply directives effectively), and developers would then have to create their own apply directive based classes, to override, and if we change something in the core theme, they'd have to hold off on updating (and thus miss out on new features), until they're able to add it in.
Then, we'd also have to maintain the default daisy theme, while also maintaining Tailwind 2, Tailwind 3, Bootstrap 4, Bootstrap 5, and while also implementing support for the imminent release of Tailwind 4.

Then dealing with the troubleshooting that comes with "Why isn't setTdAttributes producing the right result for me with Daisy, when I've used the keithnd6-td class?"

I dunno, maybe I'm missing something here! Feel free to reach out on the Discord to discuss properly, and feel free to open a PR for review, but as far as I can tell, it'll make customising individual elements more difficult.

[keithnd6]

Hi @lrljoe,

Thanks for your detailed feedback—I really appreciate it.

I understand your concerns about maintaining Tailwind’s flexibility, version compatibility, and the potential for added complexity. My aim with the Daisy theme is to offer an optional layer for developers who prefer component-based styling, while ensuring that Tailwind’s default behavior and customization options remain fully accessible.

To address the concerns:

1. Maintaining Flexibility: Tailwind’s ease of overriding styles is indeed a huge asset, and I agree that we should maintain that level of customization. My intent with the Daisy theme isn’t to obstruct that but to provide an additional, optional layer for developers who prefer a more componentized approach. Daisy being built on top of tailwind would still provide the same level of flexibility.
2. Versioning: Daisy is tied to specific Tailwind versions, and this could be documented to avoid confusion.
3. Support: I’m happy to contribute to documentation and examples to ensure the theme is easy to use and customize.
4. More Tailwind apply directives: On this point, i certainly agree, because both themes co-existing is abit redundant as they both would be doing the same thing under the hood.

Ultimately, I see this as an optional enhancement for those who want it, while preserving Tailwind’s strengths. Just going to run some more tests and then open a PR and await feedback.

I will join the Discord and reach out for further discussion.

[lrljoe]

@keithnd6 - please do reach out, as I'm very open to
a) Adding more options for users
b) Adding more functionality to extend the default behaviours.

As we start to think more and more about a v4 of the package (something that we were looking at before Livewire v3 jumped out), we do want to make life easier from an extending perspective.

You may notice that in more recent releases, I've started to migrate some of the core integrations (for example, where we add x-data elements), as computed properties, as we try to abstract functional behaviours back out of the views/blades themselves
Likewise, you'll notice that we're removing a lot of the view inheritance where computed properties can be used.

The ultimate idea is to ensure that the views are purely visual, with little-to-no logic in them, but that's a v4 thing ultimately.

For now, I'm definitely keen to find a way to add this in smoothly. The key thing I think is where people are using the setXAttributes, and ensuring that this functionality is maintained (while ensuring defaults exist).