Surface - Set custom CSS error class for text inputs

Hi @im3000 !

Thanks for using Surface!

If the ErrorTag does not fit your needs, you could indeed dynamically add a class to the TextInput component with the class prop like you mentioned.

There is no currently no way to dynamically add a class to a component across the application. A solution could be to create your own TextInput component that is a wrapper for the Surface one, or that delegates the rendering to Phoenix (it is basically what the Surface component does). In that component, you can retrieve the form context and do what you want with it.

Take a look at https://github.com/surface-ui/surface/blob/master/lib/surface/components/form/text_input.ex, I am sure you will find what you need there.

That being said, I am curious how you imagine a “dynamically” class for one component could work? Could you explain us how you imagine the API? It will help us to evaluate the way of implementing this to Surface.

Thank you for the answer @Malian!

As you suggested, I could probably get away with a derived input component. What I had in mind was a tighter coupling to Ecto changesets, but that coupling might be too tight. On the other hand all the information is already probably there.

The idea sparked after reading Dynamic forms with Phoenix « Plataformatec Blog post and especially the “Customizing Inputs” section. I am thinking if Surface has an Field tag that acts as a wrapper for inputs and error tags it might be quite easy to add an error CSS class to the inputs that the field is wrapping. With that said, I haven’t looked at the Surface’s code too close yet so take my thoughts with a pinch of salt.

What do you think? Is it doable or is it not in line with Surface’s design philosophy?

Very doable - but not a native surface concern.

Phoenix does a bit of magic to hide errors on fields the user has not yet interacted with.
This ‘magic’ is done with these classes when using ErrorTag:

  .phx-no-feedback .invalid-feedback {
    display: none;
  }

Obviously display:none; would not work on a border - and this will have to be modified achieve applying an error border to a field.

Think you would apply a default border if .phx-no-feedback is present, and when just .invalid-feedback is present on the field, apply the error border or similar…

Could also use more intelligent CSS selectors like if .invalid-feedback is present on a parent node - to apply certain styles…

@harmon25 correct me if I am wrong, but Phoenix add phx-no-feedback from the error_tag function in your ErrorHelpers module. Does Phoenix add phx-no-feedback on inputs as well?

No phoenix does not do that for you, the dom node needs an accurate phx_feedback_for attribute - Form bindings — Phoenix LiveView v0.15.7 (hexdocs.pm) to apply the phx-no-feedback class.

So a special styles like:

input .phx-no-feedback.invalid-feedback {
...
}

input .invalid-feedback {
...
}

would be required to pull this off, as display: none; is not really an option for the input itself

I am a bit confused. If Surface could add some kind of css class to the <form> or <div> (Field) element in case of field error it would be no problem doing a little CSS-fu to style the inputs in question. Right now the generated DOM node for ErrorTag hangs on its own and there is no easy way to find its input without doing some JS-fu.

Right now I’ve solved it with a hack adopted from the article mentioned higher up, but I feel there must be a better way.

<Form for={@changeset} change="change" submit="save" opts={autocomplete: "off"}>
   <Field name={:name}>
     <Label class="form-label" />
      <TextInput class={'font-medium', 'w-full', invalid: state_class(@changeset, :name)} />
       <ErrorTag />
    </Field>
</Form>

And I put this helper func in my LiveHelpers module that I then imported in my Surface component.

  def state_class(changeset, field) do
    cond do
      !changeset.action -> false
      changeset.errors[field] -> true
      true -> false
    end
  end

TBH I feel like that meme science dog atm .. hehe. Still learning! But something tells me that this could somehow be solved in the Surface lib itself. Either by Surface configuration or maybe in some kind of a separate helper module.