Can't customize input classes

[edalzell]

As mentioned here: #653, I'm trying to create a text input but I can't customize the input classes.

I'm trying to make:

<div>
  <label for="email" class="block mt-2 text-sm font-medium leading-6 text-white">Email Address</label>
  <div class="mt-1 sm:mt-0 sm:col-span-2">
    <div>
      <input
        wire:model="email" 
        wire:keydown.enter.prevent="nextStep" 
        id="email" 
        type="email" 
        placeholder="[email protected]" 
        autocomplete="email" 
        class="block w-full border-0 py-1.5 shadow-sm ring-1 ring-inset ring-gray-300 placeholder:text-gray-400 focus:ring-2 focus:ring-inset focus:ring-lime-300 sm:text-sm sm:leading-6 font-mono"
      >
    </div>
  </div>
</div>

Without publishing the stubs. I'd love an inputClasses prop or something I could pass stuff into.

[jeffchown]

@edalzell Have you looked at the docs for the Longhand version of a flux:input?

https://fluxui.dev/components/input#longhand

You should be able to apply your classes directly to the input using this approach.

(And could also build you own custom component for easy reuse)

[edalzell]

That's still not the direct input field though, that's what I need to add the classes too.

I don't really want to build a custom component for something as simple as a text input where I need to customize the input classes.

I realize there are several ways around it, but none of them feel right for something basic like this, IMO.

[igmltd]

That's still not the direct input field though, that's what I need to add the classes too.

I don't really want to build a custom component for something as simple as a text input where I need to customize the input classes.

I realize there are several ways around it, but none of them feel right for something basic like this, IMO.

I completely agree with @edalzell, I have been hacking away - there are some basics that requires a little too much time - if the solution is always publish or make your own, you then find yourself on the pathway of creating your own component library and going back to a life before flux.

I believe @calebporzio is working a more approachable solution to customisation, colors, radius etc

#176

I love flux, the idea of flux as well as everything @calebporzio does, however there’s something not quite right in the air - but hopeful things will clear up.

[jeffchown]

@edalzell @igmltd I see what you are saying. The class="..." is applied to the flux:input's wrapping div.

To address that, I've been using CSS to globally tweak, when needed (via data-flux-control, type="email", etc.), my flux:inputs which works for widespread changes but is not ideal for one-offs (where I have to resort to e.g. class="[&>input]:text-red-600"), which an approach like an input-class attribute or something similar would address.

In case this helps, for my global Flux CSS tweaks, I use blocks similar to this in my app.css file, e.g.:

ui-field>div>input[type="email"] {
    @apply text-green-600;
}

Has taken a bit of exploration and experimentation... #cssishard.

[ju5t]

blade-tailor looks promising. I haven't tested it yet, but I think this the cleanest approach which doesn't involve publishing components.

[edalzell]

In case this helps, for my 'global' Flux CSS tweaks, I use blocks similar to this in my app.css file, e.g.:

ui-field>div>input[type="email"] {
    @apply text-green-600;
}

Ya, again that seems ok (but still kinda gorpy) for site-wide changes, but not per component.

[calebporzio]

Yeah, I think the best you can do right now is using nast tailwind like this: [&>input]:your-classes.

I agree, this isn't ideal - It's a pretty tough problem to solve otherwise, so I think your suggestion, an inputClasses prop might be the best we can do (although it feels like a hack).

Another alternative is exposing aninput prop that captures classes, however I'm not sure that's any better.

I'll think about this a little and get back to you when I'm back in the office (I'm on a trip right now).

[calebporzio]

Hey, @igmltd, curious what you mean by this? "there’s something not quite right in the air"

What exactly is not right? I want to make sure Flux is a good as it can be so I'm extremely interested in what might cause a statement like this.

[igmltd]

Hey, @igmltd, curious what you mean by this? "there’s something not quite right in the air"

What exactly is not right? I want to make sure Flux is a good as it can be so I'm extremely interested in what might cause a statement like this.

Hi @calebporzio thanks - what I meant was isolated to the styling and theming side of things - a lot of the times it all feel a little to "hacky" to style or modify to fit a project - and then publishing seems to be the easiest thing to do, but the most unwanted thing to do - especially with updates coming in thick and fast.

So that statement was specifically referring to just that - knowing it will clear up in time once theres a solution you're content with.

Your commitment and passion is clear, myself and I'm sure everyone else, also wants this to be the best - and it already is in a lot of ways. I think every early adopter also knows we get to help you shape this for those to come - it's ride or die for me.

Sometimes just pointing a negative can also dismiss the fact that everything else that has not been mentioned is loved and appreciated beyond thanks.

[DonCamillo11]

I'm currently working on the same topic. I was really excited when Flux was announced. I wanted to use Flux to replace all the elements in my project accordingly. Unfortunately, I stumbled relatively quickly over the customizability of the elements. For me, it has actually turned out that it is unfortunately not really usable at this stage. The adjustments are far too complex, the aim should be to be able to adapt without publishing the stubs and possibly in a central location. But at least in the expected places.

As an example, I recently stumbled upon the checkboxes. I simply wanted to reduce the space after the label. This didn't work the usual way of assigning my own classes. Then I noticed that all the formatting of the label is defined in the <ui-field> element above it. It looks something like this
[&[disabled]_[data-flux-label]]:opacity-50 [&[disabled]_[data-flux-legend]]:opacity-50 [&>[data-flux-field]]:mb-3 [&>[data-flux-field]]:mb-3 [&>[data-flux-field]]:mb-4 [&>[data-flux-field]:last-child]:!mb-0 [&>legend]:mb-4 [&>legend:has(+[data-flux-description])]:mb-2 [&>legend+[data-flux-description]]:mb-4

It gets even more extensive with the above-mentioned
https://fluxui.dev/components/input#longhand

There the <ui-field> element looks like this:
min-w-0 [&:not(:has([data-flux-field])):has([data-flux-control][disabled])>[data-flux-label]]:opacity-50 [&:has(>[data-flux-radio-group][disabled])>[data-flux-label]]:opacity-50 [&:has(>[data-flux-checkbox-group][disabled])>[data-flux-label]]:opacity-50 block [&>[data-flux-label]]:mb-3 [&>[data-flux-label]:has(+[data-flux-description])]:mb-2 [&>[data-flux-label]+[data-flux-description]]:mt-0 [&>[data-flux-label]+[data-flux-description]]:mb-3 [&>*:not([data-flux-label])+[data-flux-description]]:mt-3

This is quite complex to understand and certainly not what I expected. Especially if you are a design-savvy programmer and want to adapt the elements to your own design, you quickly stumble.

For me, the adaptations are unfortunately much more time-consuming than creating my own elements.

[edalzell]

I agree, this isn't ideal - It's a pretty tough problem to solve otherwise, so I think your suggestion, an inputClasses prop might be the best we can do (although it feels like a hack).

It is a bit hacky, I agree, but a better hack, cuz you now get per component customization, and you can still use the tw/laravel class merge stuff.

I'll think about this a little and get back to you when I'm back in the office (I'm on a trip right now).

Thanks Caleb, I know you wanna make this perfect. I believe in you!

And I do really want to use this instead of our custom components, this is the only thing holding me back. But I already purchased a full license cuz I wanna keep you in your high end fishing gear!

[ju5t]

I already posted the link here but I feel that should be the default way of adjusting components in Flux. Although the example below is a bit extensive, the syntax is clean & simple. I would prefer this over inputClasses.

Tailor::component('flux::button')
    ->props([
        'variant' => 'primary', // Customise prop defaults
        'huge' => false, // Add new props
    ])
    ->classes(fn ($variant, $huge) => [
        'border-4 rounded-full -rotate-2 !shadow-drop-1g',
        'scale-150' => $huge,
        '[&>[data-flux-icon]]:: text-orange-500 size-10 -mx-2 mb-0.5 self-end',
        match ($variant) {
            'primary' => 'border-blue-300',
            'danger' => 'border-red-800',
            default => '',
        },
    ]),
    ->attributes([ // Add new attributes
        'data-thing' => 'foo',
    ]);