Pattern-match callbacks

[waralex]

Pattern-match callbacks.

The functionality is the same as in Python, with a single nuance - NamedTuple is used as the id:

callback!(app,
    Output((type = "output", index = MATCH), "children"),
    Input((type = "dropdown", index = MATCH), "value"),
    State((type = "dropdown", index = MATCH), "id"),
) do value, id
    return html_div("Dropdown $(id.index) = $(value)")
end

[alexcjohnson]

Yep, that should be fine - this only happens when starting the server anyway, we only really care about efficiency during callback requests. Readability and simplicity are more important here.

[alexcjohnson]

FYI I see a few trailing whitepaces added in this PR (and a few others removed) - it's a little easier to review if we never have these, do you use an editor that can be set to automatically strip these on saving?

[alexcjohnson]

Is the resource refactoring here solving a problem, or just simplifying the structure?

[waralex]

@alexcjohnson

Is the resource refactoring here solving a problem, or just simplifying the structure?

Initially, I took resources from the R version, where they were grouped into folders. Now it turned out that this version of resources does not support pattern-matching, so I updated the resources to those used in Python dash 1.13.2. Python dash does not split them into directories, and it seemed to me that this is more convenient.

[alexcjohnson]

Beautiful. I don't know all the data type options in Julia, but I can't really imagine a simpler syntax than what you have here with NamedTuples. It looks like this is handled self-consistently, meaning that when you get a pattern-matching ID in callback_context it's also a NamedTuple? If I'm interpreting that right, then I'd say let's do it! 💃

[waralex]

@alexcjohnson

It looks like this is handled self-consistently, meaning that when you get a pattern-matching ID in callback_context it's also a NamedTuple?

It depends on which context parameter we are talking about. inputs_list, states_list, and outputs_list- Yes, id is NamedTuple. In triggered and inputs and states dictionaries, the keys are like in Python-strings from json with sorted keys + .<property>. On the one hand, for consistency with the Python api, on the other, because in this form they come to changedProps from the front end:

triggered : [(prop_id = "{\"action\":\"done\",\"item\":3}.value", value =["done"])]
inputs:  Dict("{\"action\":\"done\",\"item\":3}.value" => ["done"])
inputs_list: [(id = (action = "done", item = 3), property = "value", value = ["done"])]
outputs_list: [(id = (item = 3,), property = "style")]

In principle, there is no big problem to make the keys also NamedTuple. Just keep in mind that the order of fields is important in NamedTuple, i.e. (a=1, b=2) != (b=2, a=1)

[alexcjohnson]

On the one hand, for consistency with the Python api, on the other, because in this form they come to changedProps from the front end

Perfect. 💃 still applies.