Thoughts on mutually recursive hyperviews (Children talking to Parents)

[adithyaov]

Thought Experiment:

Parent.hs

data Parent = Parent deriving (ViewId)

class HyperView Parent es where
    data Action Parent = Refresh
    update = do
        ...
        ...
        hyper Child $ ...

Child.hs

data Child = Child deriving (ViewId)

class HyperView Child es where
    data Action Child = UpdateSomething
    update = do
        ...
        ...
        trigger Parent $ Refresh

These are mutually recursive HyperViews.

If I want functionality like the above, I’m forced to keep both Parent and Child in the same module.
This becomes messy if I want to keep Parent and Child in separate modules.

However, this mutual recursion is unnecessary.

• The update of Parent depends on data Child.
• The update of Child depends on data Parent and data Action Parent.

The update functions themselves aren’t mutually recursive -
they only appear to be because both Action and update are tied to the same class.

It should be possible to split HyperView into two parts:

class HyperViewDef id es where
  data Action id :: Type
  type Require id :: [Type]
  type Require id = '[]

class HyperViewImpl id es where
  update :: Action id -> Eff (Reader id : es) (View id ())

This split provides much more flexibility in how functionality can be organized.
It also makes conceptual sense to separate definitions and relationships from implementation.

There may be better ways to approach this.
The use case described above represents a very natural way to think about UI structure and how UI elements should communicate.

[seanhess]

Good point! I always put all my hyperviews in the same file, even in a large application, so this hasn't come up before.

I worked very hard to make the class ergonomic and painless to use, the proposed solution is too complicated, but maybe you could figure something else out.

One thing to keep in mind is that while it is very natural to structure modules this way, organizing applications into reusable hyperviews results in brittle object-oriented-like code. Perhaps forcing them all to be in the same module also forces users to come up with other methods of factoring (like composable functions!)

It also makes conceptual sense to separate definitions and relationships from implementation.

That's not intuitive for me, can you explain why that feels more intuitive to you?