Feature/dynamic element

[wokalski]

Imagine there's no key
It's so yum yum if you try
No conflicts upon us
Elements side by side

Imagine all the components
With typed identities

This PR removes keys and removes lists as the container for sequences of elements. Instead of keys you can use constant identity like so:

let%component reorder = (~flipped=false, ()) => {
  open Components;
  let%hook text1 =
    <movableStateContainer> <Text title="x" /> </movableStateContainer>;
  let%hook text2 =
    <movableStateContainer> <Text title="y" /> </movableStateContainer>;
  flipped ? <> <text1 /> <text2 /> </> : <> <text1 /> <text2 /> </>;
};

Dynamic list API is not done yet but it will be amazing. Believe me.

Btw, if you use the component returned by movableStateContainer multiple times the result is undefined but in the future I'll make it so that all resulting instances will share state but won't share the view.

let%component reorder = (~flipped=false, ()) => {
  open Components;
  let%hook text1 =
    <movableStateContainer> <Text title="x" /> </movableStateContainer>;
   /* Three texts but they share the internal state */
   <> <text1 /> <text1 /> <text1 /> </>;
};

They will be essentially cloned.

[glennsl]

Would it be possible to add a phantom type variable to the element type, so that "compound" elements can be distinguished from "simple"/"single" elements? I believe that would allow components to restrict themselves to only accepting a single child. E.g.:

let make = (~children: element(single), ()) => ...

And listToElement, for example, would then be: list(element(_)) => element(compound)

[wokalski]

@glennsl I'm afraid no.

let fragment = <> <ImSingle /> <ImSingle /> </>
<IJustWantOneChild> {fragment} </IJustWantOneChild>

OOps

[glennsl]

Couldn't fragment just be element(compound) outright? While that would exclude the possibly valid use of a fragment with a single child, that doesn't seem like a big deal.