<select>: option is not not selected if value is an integer

[SmithChart]

I found some strange behavior where I am not sure what part of lona may be the problem. See the following reproducer:

from lona.html import HTML, Option, Select
from lona import LonaApp, LonaView


app = LonaApp(__file__)


@app.route('/')
class MyView(LonaView):
    def handle_request(self, request):
        html =HTML(
            sel := Select(bubble_up=True)
        )
        sel.append(Option("Text 1", value="a"))
        sel.append(Option("Text 2", value="b"))
        sel.append(Option("Danger", value=3))

        while True:
            event = self.await_input_event(html=html)
            print(sel.value)

app.run(port=8080)

When surfing to the view the Text 1 Option is shown inside the <select>. When I now drop the menu down and select Text 2 b is printed to the console. Selecting Text 1 prints a, as expected. When selecting Danger, however, the value printed is a, not 3 as expected.

Frontend-to-server communication looks valid. But I noticed that my 3 get's transferred as a string on the websocket.

I have traced this problem down to https://github.com/lona-web-org/lona/blob/5af71684d345f6b4f8bc79cd4d880971a30f2e2e/lona/html/data_binding/select.py#L122 . It seems the selection from the frontend is not represented in the corresponding Option: In line 124 of that file value is empty.

Using a str(3) or "3" instead of the integer works as expected. From a user perspective it should not matter if I put an integer or string in there. (It would actually come in handy since I could use the primary keys from my db in there :-D )

[fscherf]

Hi @SmithChart,

Hm! I agree, if i set an int based value, i want to be Select.value int based as well. Maybe the client should send the index of the selected value, instead of the value it self.

[SmithChart]

Sounds like the right way to go.

[fscherf]

@SmithChart: I started working on this yesterday and realized that the whole API of html.Select is quite confusing and unpractical, so i refactored the whole thing, with your issue addressed as well. Currently there is not much documentation (only in the patch description) but at this moment it's only a proposal.

Branch: https://github.com/lona-web-org/lona/tree/fscherf/topic/refactor-select-api

@maratori, @grigolet, @laundmo: Would you mind to have a look too?

[maratori]

the whole API of html.Select is quite confusing and unpractical

What's wrong with it?

Would you mind to have a look too?

First of all it has breaking changes.

Also I don't understand why do we need to use indexes. In your branch attribute contains string representation of the value. Original value is stored separately. Why not to use that string representation to find the option.

[fscherf]

the whole API of html.Select is quite confusing and unpractical What's wrong with it?

Currently, option text, value and selected state are accessed via Select.values. The abstraction should be Select -> Option -> {value, selected, disabled}. Also if I select one option, the others should be unselected automatically.

First of all it has breaking changes.

Yes thats true. First i thougt we could name it lona.html.Select2 but thats quite inelegant and produces problems with the parsing api. I would make that change in lona2

Also I don't understand why do we need to use indexes. In your branch attribute contains string representation of the value. Original value is stored separately. Why not to use that string representation to find the option.

I agree with @SmithChart that it would be very handy if the values could be anything without the need to typecast it back. Is that to much magic? I agree, you could argue thats not what you would expect what the browser would do

[maratori]

Is that to much magic?

Not for me.

typecast it back

You don't need to typecast it back. You just need to find the right option somehow and take arbitrary value from it. In your branch search is happening by index, I propose to search by string attribute.

[fscherf]

@maratori: how would i distinguish between 3 and '3' if I create strings of both of them? The event would state '3' in both cases

[maratori]

@fscherf Yeah, you are right. Moreover you can have several options with the same value '3' and browser correctly handles it. Seems it's possible only with indices.

[fscherf]

@maratori: Ok. So if you don't think its to much magic to store the actual value separate and you agree with my index approach, should i create a pr? I created a branch named lona2 where i intend to collect all patches for Lona 2. I would create the pr against that branch.

[maratori]

@fscherf Yeah, sure.