Is the EnvironmentState experiment equivalent to Flutter's Provider package?

[glen-nicol]

Howdy, I recently saw that this library moved to a component model and I think its looking great! After seeing the hooks for state and effect I wondered if the context had similar semantics to Flutter's BuildContext with respect to access to logical parents of a component (Widget in Flutter terms). Kinda seems like the EnvironmentState type in the experimental code does some of this and that allows for something like reading state from a parent provider similar to Flutter's provider package. Is that an accurate assessment?

If so, what's the story of that experiment? Are you looking for testing or help developing that functionality?

[JaggerJo]

Hey Glen 👋

Yeah, the component model is quite nice.

I've never used Flutter, so I can't really compare FuncUI to it. The IComponentContext is used only within a component and basically holds it's state, ...

FuncUI Components are just regular Avalonia UI Controls. Avalonia places them in a hierarchy (Logical Tree, Visual Tree) that you can inspect.

The EnvironmentState uses that concept under the covers to share/pass state across components that are direct or indirect Childs of an Environment State Provider. Think of it as an implicit way to pass state down, or get state relative to the context a component is placed in.

It's experimental because the API might change and we did not get enough feedback on it yet.

[glen-nicol]

Awesome, seems like its a good analog in that its more or less the representation of the components state and location in the tree. Is there an example or test for EnvironmentState to show how to use it? I see the functions readEnvValue and useEnvState but I have to admit I am confused by the first parameter.

[JaggerJo]

Here is an example of how to use it:

Avalonia.FuncUI/src/Examples/Component Examples/Examples.EnvApp/Program.fs

Line 33 in 28e60d4

let brush = ctx.useEnvState (SharedState.brush, renderOnChange = false)