chore: add `required` option to LiveSelect

[itamm15]

Is there any obstacle that LiveSelect currently doesn't support a required attr? If not, then I can work on adding that :)

[egeersoz]

I actually came here to ask for the same thing. The omission of this basic HTML functionality is somewhat bewildering.

[maxmarcon]

@itamm15 required is an attribute for front-end HTML validations controlled by the browser. LiveView forms work with validations that run on the backend. That's the reason why I never thought of adding it.

Can you please elaborate a bit on when/how you would use it and why do you believe it's necessary?

If we decided to add it, an immediate problem that I can see is that in tags mode the text input element will be empty even if something is selected, and the front-end validation will fail, even it really shouldn't.

[itamm15]

Hi @maxmarcon, thanks!
The reason is simple - what we have to do now if we want to require the select to not be empty is;

1. Assign a variable on mount level, is_form_valid: false,
2. You the variable in the button, <button disabled={!is_form_valid} ...>,
3. Then, add the validation via phx-chang="validate-form",
4. Check on the server level, whether the select is not empty - if is, then don't change the is_form_valid state, else is_form_valid = true.
5. The button is enabled, and the user can proceed with some action.

This is our current workaround for the required option. This whole workflow could be simply substituted by the required option.

Regarding tags - sorry, I am not that aware of this functionality, but maybe we could simply drop the required option for this mode? (in other words, forbid required option to be assigned to the LiveSelect with tags mode)

[maxmarcon]

Hi and thanks. Ok so you're not using Ecto schemas and changesets to validate your form? Because if so I believe all you'd have to do would be to use validate_required/3 and bind the disabled attribute of your button to the valid status of the form.

[itamm15]

Regarding the changsets for form - generally, yes, we do use. But this one is a bit more complicated, I would say, because we use interceptors (designed by our RAP system), and before actually executing the function triggered from the click on the form, the interceptor is being fired (and the required field is needed for the interceptor logic, not the changeset itself).
Scenario without required: We have a create event for a resource and also defined interceptors to check the permissions before executing the create event.

1. User goes to the form and doesn't fill the select (that's meant to be required, so we do normally require/validate it as described in my first comment),
2. The user clicks the create button, and interceptors are executed. Hence, boom 💥 happens 'cause the input hasn't been filled!

Hope that makes sense 😄

[maxmarcon]

I don't know what you mean by interceptor or by RAP. But if I understood you correctly, you have some front-end third-party code that expects a required attribute in the input field? It's the only case where I can see that adding the attribute might be justified, because in all other cases you can and should do everything on the server

[itamm15]

Apologies for not being clear!

• RAP - roles and permissions system
• interceptors - https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#attach_hook/4

Sample LiveView (pseudocode)

def LiveView do
 use LiveView, :live_view

 on_mount(LiveView.Interceptors, {:create, :can_create})

 def render(assigngs) do
 ~H"""
  <form phx-change="create">
   <.live_select id="some_attr_that_should_be_required" />
  </form>
 """
 end

 def mount(_params, _session, socket), do: {:ok, socket}

 def handle_info(:create, params, socket) do
  # creation logic
 end 
end

def LiveView.Interceptors do
 def mount(interceptors, params, socket) do
  value_from_live_select = params["some_attr_that_should_be_required"]
  attach_hook(interceptors, ..., fn -> end)
 end 
end 

As the value from LiveSelect is used in the interceptors (because it is required attr in the interceptors to check permissions), we are not able to validate it in the create/2 event. I hope that makes it clearer!

[maxmarcon]

ok thanks, it's getting a bit clearer, still a lot of questions. I'll pick 2:

1. why using hooks to verify if a field of a form is set instead of doing it in the submit or change events?
2. which stage of the LiveView lifecycle are you tapping into and how are the forms parameters being accessed by the hook? (Your code doesn't show that)

[itamm15]

1. So, we are checking if the field was settled in the form - from this perspective, we require it to be settled. It is just needed for further checks (e.g. db queries). (and as stated previously, now we mimicked the behaviour of the required option for LiveSelect with the change event, but the required option would just be simpler and definitely sufficient for us, as we just require this field to be settled, not actually validated),
2. So, this is done automatically by/within the attach_hook/4! 😄

https://www.youtube.com/watch?v=8UQLPQDqkMQ

[maxmarcon]

sorry, but you didn't really answer my questions. I know how attach_hook works, that's why I asked you which stage you're attaching to (handle_params, handle_event etc. ?) and how the code in your hook is accessing the parameters of the form.

Regardless of the way in which you access the form, I don't understand why you need required attribute at the HTML level. You have the form with the parameters I presume? Then you can just check whether the field you need is set 🤷 . Please tell me what I'm missing and maybe send me some code with a complete example of what you're trying to do. Thanks.

[itamm15]

Sorry for all of the confusion, @maxmarcon!
So, my main argument for the required option would be just the ease of usage. As you correctly pointed, we can achieve the same with the phx-change and then validation on the server level. But that's just a few more lines of code and an additional call to the server in exchange for 1 line and a client check.

[olafbado]

The required attribute is helpful when we have a form with a Submit button. If the user clicks the Submit button without entering anything in the input, the browser will automatically prompt the user to fill in the field. It's as simple as that.

[egeersoz]

Correct. It's a best practice when it comes to HTML forms to rely on built-in HTML validations as much as possible. The required attribute in particular is really nice because not only does it let you enforce the validation with zero code, but also saves you bandwidth.

[maxmarcon]

@olafbado see my comment above. You can do all this in LiveView

@egeersoz I don't think you're saving any bandwidth. Remember, every time the user changes something in the form in LiveView, this is a round-trip to the server. You can always bind everything in your HTML, including whether a submit button is disabled, to the state of the changeset that is backing your form. This is the basic idea behind LiveView forms, and how errors are usually rendered.

Anyway, you all seem to be really eager to have this, and I just saw that Phoenix core components have required in the list of global attributes allowed in the input fields.
Maybe we can create a MR that lets the global attributes through (including required) and sets them in the text input field.

Would this be ok?

[itamm15]

Hi @maxmarcon! What you mean is that all of the attrs provided by Phoenix will be supported by LiveSelect, right?