Add options for select field.

[Thrizian]

This PR is a followup of: #2676

I've had another go at this. Since i figured out how to get the application up and running locally, #rtfm. I'm pretty bad at writing tests so perhaps someone can help me with writing some better coverage. Is it sufficient to write a test that validates whether a data attribute is slapped onto the select input? Or do i also need to write tests that validate the working of my PR clientside(the stimulus controller) I have no experience testing stimuluscontrollers.

This should get us a nice start to get some more selectize functionality.

I've used the SelectController Stimulus Controller to handle this. We are using data attributes to get the message passed across.

This PR now adds:

• selected
• multiple
• max_items
• include_blank

Max items. Allows for selecting items up to max_items.

    kind: Field::Select.with_options(
      collection: [1,2,3,4],
      max_items: 2
    )

Multiple selecting multiple options.

    kind: Field::Select.with_options(
      collection: [1,2,3,4],
      selected: 4,
      max_items: 2
    )

Selected, allows for the selection of a specific element or multiple elements.

    kind: Field::Select.with_options(
      collection: [1,2,3,4],
      selected: 4,
    )

   kind: Field::Select.with_options(
     collection: [1,2,3,4],
     selected: [2,4],
   )

This also works with [[1, 2],[3,4],[5,6]]

   kind: Field::Select.with_options(
     collection: [[1, 2],[3,4],[5,6]],
     selected: [2,4],
   )

[Thrizian]

I've read through this

[Thrizian]

There are some merge conflicts on the application.js and application.js.map files. I'm a bit new to builds/ folders should i have or not have added those?

[nickcharlton]

We're going to try updating the builds in each commit/original PR to make things a bit easier, so they'll likely clash now.

You can do something like:

git checkout HEAD -- app/assets/builds/administrate/application.js
git checkout HEAD -- app/assets/builds/administrate/application.js.map
yarn build; yarn build:css

to get new versions and not worry about the conflicts.

[nickcharlton]

I rebased this to see if I could move it along, but it needs a bit more work.

1. The tests are failing with:

fields/select/_form uses the selected value when given
     Failure/Error: multiple: field.options[:multiple],
       #<InstanceDouble(Administrate::Field::Select) (anonymous)> received unexpected message :options with (no args)

2. We should add a feature tests so that we're testing the JavaScript behaviour,
3. We need to document the changes so other people know about it

[Thrizian]

Thanks for the rebase. I'll look into it when i find the time. Kinda working on my side project (Kamal 2, Rails 8) it does include administrate so i'll look into what i think needs love to reach the new rails standards :D.

I do expect time to be limited as i'm awaiting the birth of my firstborn, which is bound to happen 1 or 2 months.

[nickcharlton]

No worries! And of course, completed expected.

I was hoping to get the last bit over the line for you, but I'll leave you to it!

[Thrizian]

So i guess some of this does not work < 7. afaik this does not introduce breaking changes though.

Am i right to state that:

1. i should build an example in the spec/example_app.
2. write some documentation.

Anything else?

[nickcharlton]

I think that's it!

[nickcharlton]

Could you take a look at the test failures when you get a chance?

[nickcharlton]

What are these for?

[nickcharlton]

We should include a proper ending newline here, as is usual Unix convention.

[nickcharlton]

We should make sure we're providing an example spec, if this is in the right place, otherwise not include the file.

[Thrizian]

I'm struggling to find time on this at the moment. My wife got hospitalized, this is still in the back of my mind but not at the top of my list at the moment.

[goosys]

@Thrizian @nickcharlton
Is this an issue that should be discussed separately only for the Field::Select ?
I believe this should be designed with a common interface since similar requirements likely exist for other form elements as well.

For example, in a Number input, we might want to specify step=5 or min=0, and in a Date input, we might want to set start_year=2020.
In FormHelper, these can all be passed collectively using html_options = {}.
Wouldn't it be better to allow field options to be passed in a similar way, such as html_options: {} or form_html_options: {}?

Once passed via html_options, it becomes the responsibility of FormHelper, so we likely wouldn't need to write individual tests on our side.

What do you think?

[nickcharlton]

@Thrizian, I'm sorry to hear that! I hope she gets better soon.

There's no need to rush, so please take your time. It might be worth pulling out some changes, like @goosys mentions. We can give it a bit of thought.

Yesterday, you happened to get a lot of activity because I (finally) managed to spend much of the day working through my notifications and trying to move some things along, there's no urgency from me.

[goosys]

@Thrizian @nickcharlton

I think we should organize a few things before resuming this PR.

Among the options being added, I believe include_blank and selected should not be included.

For include_blank, I tested it in several cases, and while its behavior is somewhat puzzling, it is functioning correctly. Therefore, there is no need to add it. #2790

As for selected, if the model provides the data, the initial selection should be set correctly, so there is no need to forcefully add it.
If it is a virtual column, the data can be provided via a setter, meaning the option is still unnecessary. #2658

[goosys]

html_options is used as an option for show/index in Field::Url. #2139

We may need to consider a different name to distinguish it from the one used in forms. Additionally, in the future, there might be cases where multiple inputs are linked within a single Field form. In such cases, it may also be necessary to use a name that clearly indicates which input the options apply to.