Add class names to all components for easy customization.

[fazdiu]

This component is great but it's hard to customize with tailwindcss. For example, I have 20+ tables and it was tedious for me that I have to repeat the css classes in each table. So my suggestion is to put class names in all the components. In this way it would make it easier to customize with css.

[lrljoe]

You should use a trait if you need to repeat code across multiple components such as applying the same configure() options.

The idea behind tailwind is class reuse without needing to create or specify extra class names, while keeping the built file to a minimal size. So there's no benefit to creating custom class names.

[lrljoe]

It uses standard classes for tailwind and bootstrap, no custom classes.

You can always publish the views and amend as you wish, but keep in mind that this isn't recommended as they are subject to change.

I'd definitely recommend creating a custom trait, and just adding it to your table components, and use the lifecycle hooks to do the work.

I do this for setting up some standardised configuration elements across different tables.

[fazdiu]

A good idea of ​​the traits. But in
some components do not allow you to add attributes or class names. For example, input text filter, dropdown filter button, bulk actions button, columns button. These are some components that do not have any kind of customization. Do you have any ideas to customize those components?

[fazdiu]

There are endless possibilities for css customization.
Being able to identify a filter dropdown, for example, would convert them to rows when on very large screens and vice versa. What I mean is that perfect designs can be achieved without much complexity.

[lrljoe]

For the overall filter displays, there's the option of using the slide-down filter display.
This does allow you to set the columns/row for the filter rather than pop-over. If your users are more desktop-driven than mobile, then this is definitely a cleaner approach.
I do plan to implement columns for the filter pop-over display, but this needs some consideration before I do it.

If you want to customise a particular view completely, then publish the views, and change the blade code in whatever way you like. I suggest that you remove any published views that you haven't changed to minimise any issues with disparities between the core blades, and your own. Keep in mind that any new features will require you to manually add the changes in to your custom blade(s).

You can of course over-ride the behaviour of the default classes, if you add the relevant targeting into your app.css file to over-ride the default behaviour.

If you're needing help with targeting a particular element, then please let me know which, I can certainly look at where adding attributes to certain elements to help with targeting if needed.

Future versions will likely have more configure options to allow users to customise the classes used, but there's no intention as far as I'm aware to start implementing custom class names as that'd mean people having to publish public files, and would be a breaking change.

[lrljoe]

If you find any components that you'd like to add custom classes to where you're not currently able to. Please open a feature request for that item.

Most core elements do have a method for setting custom classes.