Added the StateLayout

[sthewissen]

Description of Change

This PR adds StateLayout and all of its helper classes. This is currently up as a separate NuGet called "StateSquid" here:
https://www.nuget.org/packages/Xamarin.Forms.StateSquid 🦑

Bugs Fixed

• Implements [Spec] StateLayout #275

API Changes

Added all the classes as already described in #275. The only thing I haven't put in here is the SkeletonView that was mentioned there. I don't want to take that in to be honest, as I think it should be up to the user to create their own visualization. I'm sure we could come up with a better skeleton loading solution anyway.

PR Checklist

• Has tests (if omitted, state reason in description)
• Has samples (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Changes adhere to coding standard
• Updated documentation

[sthewissen]

I hope to be able to add some documentation for this and can port some of the existing samples from the repo. Not sure if I'll come around to writing some adequate tests due to time constraints, so if anyone is up for that feel free to add them.

[jfversluis]

Builds 🎉

[AndreiMisiukevich]

I wonder, is there any sense to keep enum if we cannot describe all possible cases?

Maybe we can refactor it to static class (similar to how XF Device class operates with RuntimePlatform)

public static class LayoutState {
    public const string None = nameof(None);
    public const string Loading = nameof(Loading);
    /// etc.
}

[sthewissen]

Been trying this but so far it's been a bunch of misery :P The custom state is explicitly added for scenarios not covered by the default states. Also making it a string introduces some strange scenarios where the user has to explicitly set a value for it to work. We can fix that in the component obviously, but it feels a bit strange.

[AndreiMisiukevich]

Hmm, LayoutState?

State is too general, I believe

[sthewissen]

Thing is, that would mean we have StateLayout and LayoutState. That confuses me even more 😅

[AndreiMisiukevich]

Yeah, that's fair. But if we will add several new controls which have "State" property, it will confuse not less :)

[sthewissen]

Agree. Perhaps I shall think a bit longer on an alternative :)

[jfversluis]

Are we still going to change this name?

[sthewissen]

Open to suggestions :)

[AndreiMisiukevich]

Hmmm, something went wrong with rebase, I guess

[sthewissen]

Hmmm, something went wrong with rebase, I guess

Working on it :)

[sthewissen]

I rebased once more. Unless we can come up with a better name I'd say leave State as is for now. ViewState is a possible alternative, but that can also be a bit confusing. Regarding making the State constant strings, I'm personally not a fan as it would require quite rewriting and logic adjustments. I personally don't have the time for that and would make migration for existing users more cumbersome (I think). @jfversluis @AndreiMisiukevich

[AndreiMisiukevich]

I rebased once more. Unless we can come up with a better name I'd say leave State as is for now. ViewState is a possible alternative, but that can also be a bit confusing. Regarding making the State constant strings, I'm personally not a fan as it would require quite rewriting and logic adjustments. I personally don't have the time for that and would make migration for existing users more cumbersome (I think). @jfversluis @AndreiMisiukevich

That's up to you.
But I do like "LayoutState" name. Similar to "ExpandState" in Expander. Or StateLayoutState.

[sthewissen]

@AndreiMisiukevich I renamed to LayoutState, let's see how it goes :)