Lift "graft" to the level of components about purescript-halogen

[paf31]

A direct translation of graft would require something like pi-types, since we have an existential on the right hand side of a function arrow:

graft :: Component p m node req res -> (p -> Component q m node req res) -> Component q m node req res

Here, the hidden input type of the second (dependent) component depends on the value of type p. Without pi-types or some kind of cast, I don't think we can represent this faithfully.

An alternative is

graft :: Component Unit m node req res -> Component q m node req res -> Component q m node req res

where we only allow one placeholder position.

I'll spend some time thinking about this, but I think it might be best to push it to the next milestone for now.

@jdegoes, what do you think?

[jdegoes]

Something along the lines of this:

install :: forall p p' a a' b b' m node. 
  Component (Either p p') m node (Either a a') (Either b b') -> 
  (p -> Component Void m node b' a') -> 
  Component p' m node a b
install parent child = ...

parent `install `(const createAceComponent)

Although one can quibble about details, such as whether the placeholder of the parent should be Either p p', just p with a Prism (how to get the remainder), or something else entirely, and whether or not the child may have any placeholders left (probably so, for generality???).

But the basic idea would be that the parent can perform two-way communication with the child, but after installation, only the parent's external channels are visible. This provides a nice, infinitely composable mechanism to nest components within each other in a way that still facilitates structured communication and declarative composition.

[paf31]

This would work, apart from the types-depending-on-values issue again. We could probably work around it with some kind of Any type and some unsafe trickery.

[jdegoes]

You mean in the implementation, right? The type signature seems externally safe.

install' :: forall p p' p'' a a' b b' m node.
  Component (Either p p'') m node (Either a' a) (Either b' b) -> -- the parent component, which can talk to the child
  (p'' -> Component p' m node b' a')                          -> -- creates a child component from the placeholder
  Component (Either p p') m node a b                             -- the parent component, installed with the children
install' parent child = ...

parent `install'` (const createAceComponent)

-- simplified case when child component has no more placeholders
install :: forall p p' a a' b b' m node.
  Component (Either p p'') m node (Either a' a) (Either b' b) -> -- the parent component, which can talk to the child
  (p' -> Component Void m node b' a')                         -> -- creates a child component from the placeholder
  Component p m node a b                                         -- the parent component, installed with the children

-- maybe combinators to make things clearer???
respondChild = respond <<< Left
respondParent = respond << Right

accept child parent = accept <<< either child parent

[paf31]

Yes, externally it's fine. The problem is how to instantiate the existential type inside when constructing the resulting component. Really the type should satisfy something like T (install c f) = exists a. Either (T c) (T (f a)) where T is the type level function which picks out the type used to instantiate the existential inside Component. Practically, I think it has to be Any.

[jdegoes]

Crud. Well, as long as we can package up any messy details behind a safe, clean API, I'm in favor of it.

[paf31]

As I mentioned elsewhere, an alternative to using placeholders which I prefer is to have components take internal components as function arguments. This makes the dependency very explicit, and also allows us to have component require a Maybe Component or a List of Components etc.

[jdegoes]

I'd like to learn more about that strategy; I don't see how it would provide (a) fine-grained placement of a child component inside the DOM of a parent component, and (b) type-safe parent-child, bidirectional communication through req / res.

[paf31]

1. It's as fine grained as you like - you would just take a Component and place its content wherever you like in the HTML structure.
2. I think it's at least as strong as this proposal, since you could theoretically just use graft inside your component to place the subcomponent.

I'll try to come up with an example.

[jdegoes]

I'll try to come up with an example.

That would be nice. Many components (e.g. a two-column pane that allows adjusting width between the panes) are generic in the type of children installed into them. That's partially what made me think of placeholders, because placeholders allow you to define components with holes in them, and later fill them in generically as the context requires (including, potentially, installing children and supporting bidirectional and type-safe communication between parent and children). If we can achieve all these goals cleanly and more powerfully without something like install, then 👍 .

[paf31]

I started working on modifying the Ace demo to create a generic two-column component, as an example of this, but it basically just boils down to partially applying combine. combine is one example of combining two components with this approach, but not the only one. Generally, you want to apply runComponent to get at the internals of the Component, and use the Profunctor (etc.) machinery to build a new Component generically. You could even mix in another signal function using mergeWith to provide additional inputs (e.g. to control the relative widths of the two columns).

For bidirectional communication, I think some kind of hide combinator would be nice:

hide :: forall p m a b i. Component p m (Either i a) (Either i b) -> Component p m a b

The point is, there is no bidirectional communication apart from at the top level, where you need something of type Component p m a a, and we tie the knot. hide can help to reduce some of the destructuring and reassociating needed to make this work.

I'll spend some more time on this tomorrow hopefully.

[jdegoes]

The point is, there is no bidirectional communication apart from at the top level, where you need something of type Component p m a a

Well, that's not necessarily true, e.g.:

install :: forall p p' a a' b b' m node.
  Component (Either p p'') m node (Either a' a) (Either b' b) -> -- the parent component, which can talk to the child
  (p' -> Component Void m node b' a')                         -> -- creates a child component from the placeholder
  Component p m node a b                                         -- the parent component, installed with the children

Here the parent component can send and receive messages to the child component.

For bidirectional communication, I think some kind of hide combinator would be nice:

This definitely sounds like a nice and general-purpose combinator.

[paf31]

I'm just saying that communication is never direct. An event always bubbles all the way to the top level, gets run through some handler function, then gets pushed back through the signal function graph.

[jdegoes]

I'm just saying that communication is never direct.

That's not true with anything that's existentially hidden, though, is it?

[paf31]

Yes, still true. We could save some round tripping of events for existentially hidden things, since the types basically tell us there is only one place they can go, but it would require a significant reimplementation at the top level, and I'm not sure I fully see how it would work yet. I'll have a think about it.