Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added optional Select input binding #847

Merged
merged 3 commits into from
Sep 1, 2021
Merged

Added optional Select input binding #847

merged 3 commits into from
Sep 1, 2021

Conversation

minettiandrea
Copy link
Contributor

First of all thank you very much for the great product. I'm a very happy udash user! And using it extensivly on my open source project https://github.com/Insubric/box

For my projects I'm using quite a lot the native HTML5 form validation, an in general with udash it works smoothly, I just come across a minor limitation on the select element, using required on the select element with the current implementation does not trigger any validation and we have no way to put a null option, but there are use cases where this is needed.
For reference see MDN select required documentation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#attr-required.

In order to overcome this limitation my proposition is to add a optional method on io.udash.bindings.inputs.Select with that signature:

def optional[T](
    selectedItem: Property[Option[T]], options: ReadableSeqProperty[T], labelNoValue:Modifier
  )(label: T => Modifier, selectModifiers: Modifier*): InputBinding[Select]

basically is the same of the apply just the selectedItem is optional and we need a label when no value is selected.

The usage is pretty straightforward.

Thanks

Andrea

@ddworak ddworak self-requested a review August 24, 2021 06:50
@ddworak
Copy link
Member

ddworak commented Aug 24, 2021

Thank you for your kind words, it's always great to see Udash successfully used outside of our org :)

Regarding the PR, I'm not yet convinced that it improves upon the current API so much - I think I may be missing some use case. Let's assume:

val fruitProperty = Property[Option[Fruit]](None)

Then the current Select could be used like:

Select(
  fruitProperty, Seq(Apple, Orange, Banana).map(_.option).prepended(None).toSeqProperty
)(maybeFruit => maybeFruit.mapOr("Label no value", _.name))

and the new, utility one:

Select.optional(
  fruitProperty, Seq(Apple, Orange, Banana).toSeqProperty, labelNoValue = "Label no value"
)(_.name)

Sure, we get to avoid boxing in .option and prepending explicitly, but if the renderer for labels is any more complex, you'll have to call it separately in each arg list. Maybe if you show your example, we can find a nice interface to cover it.

@minettiandrea
Copy link
Contributor Author

Hi @ddworak ,
thank you for replying

my example it's no more complex from what you wrote, the need of adding the optional method was for the rendered output, with the current implementation you will have something like:

<select>
   <option value="0">Label no value</option>
   <option value="1">Apple</option>
   ...
</select>

but you won't be able to use HTML5 required since "Label no value" has 0 in the value attribute

with my implementation you'll get:

<select>
   <option value="">Label no value</option>
   <option value="0">Apple</option>
   ...
</select>

so if "Label no value" is selected and the element is required the validation fails as expected.

But I agree that we could just change the underlying implementation.
Here (L21:SelectBinding.scala) :

 val el = option(value := idx.toString, label(opt)).render

if opt is None we can set the value as empty string instead the index, but I don't know if that could break things somewhere else, of course the onChange method should be changed accordingly.

If you like that idea I can update the PR with the implementation

Copy link
Member

@ddworak ddworak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh now I see. I think you were right to create a separate method then - it's a different behaviour - we just need more clarity for the user as to what the differences are.

@ddworak ddworak added this to the 0.9.0 milestone Aug 26, 2021
@minettiandrea
Copy link
Contributor Author

Thank you for reviewing my code.

I did the changes you suggested and added a test case.

Copy link
Member

@ddworak ddworak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for these improvements. I've left 2 minor comments and I think we'll be ready to ship after that.

@minettiandrea
Copy link
Contributor Author

Done, when you think it could be available on maven central?

Copy link
Member

@ddworak ddworak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thank you for nice contribution :) I'll push the M17 tag right after merge, so it'll be available as soon as the central processes the artifact, usually a couple hours.

@ddworak ddworak merged commit 3f31e2d into UdashFramework:master Sep 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants