Allow Key and KeyOrValue to be treated as Data

[rjwittams]

To let them be part of a data argument.

[cmyr]

This feels iffy to me, because for a Key the actual value in the env that the key resolves to could change with the key still being equal for the purposes of data, and that seems like a possible source of confusion?

[rjwittams]

The use case for this is passing KeyOrValues around e.g

• picking things in one widget, and passing them to another widget via construction in view switcher - common in widget demos/examples).
• in a complex composite (e.g table) you may have a bunch of construction time config (including things to resolve from Env) between child widgets that you promote into app data using Scope.

The general form of the problem you are worried about is trivially true for all "Data" - someone changes something outside of data that we depend on in some calculation that we cache the result of (in local widget state or data), and we don't observe for changes in the non data item.

f(Data, not-data) -> something we can't track with just .same()...

Anyone resolving KeyOrValues should either be checking if the env has changed in update and re-resolving or resolving them at the point of use. I agree that probably people don't do this everywhere. I think that is more of a generic issue with env than anything else.

It seems unintuitive to not be able to trivially pass around arguments that we give to widgets in data - meaning anyone who needs to do so will end up wrapping them up and manually implementing Data).

[cmyr]

This makes sense; I think what I would generally do in this sort of case is something like just annotate the fields with #[data(ignore)], but if you do want to know, (for the sake of Data) when the key has actually changed then this makes sense to me.

[rjwittams]

Yeah, in the table case I do want to know if the keys have changed, so I can reresolve them. But I do have to check for env changes separately as its another input to the resolution. I can see how trying to make this kind of thing 'just work' does lead towards a full on dependency graph ala SwiftUI/Adapton... erk!

[cmyr]

yea, I've definitely been struggling to find an architectural middle-ground.