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?

[adithyaov]

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

I will have to think about this a little more. I agree, the current implementation IS simpler and easier to reason about.

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.

Is a hyper view not meant to be reusable? How should I approach the concept of HyperViews?

I'll augment this issue with an elaborate requirement of UI, and I would highly appreciate it if you could give your thoughts on how you would approach building such a UI with hyperbole.

I don't think I'm going about my UIs in an idiomatic way. I think of my HyperViews as reusable widgets that I can paste into my application.

[seanhess]

Is a hyper view not meant to be reusable? How should I approach the concept of HyperViews?

I don't think I'm going about my UIs in an idiomatic way. I think of my HyperViews as reusable widgets that I can paste into my application.

I'm actively trying to discourage reusing HyperViews as widgets, but nearly everyone has the same intuition as you! I address this in the documentation: Functions, not Components

Have you read that section before? If so, what is missing or doesn't make sense. If you haven't, how can I direct people to read that documentation better? I wrote it because this sort of thing comes up all the time.

I'll augment this issue with an elaborate requirement of UI, and I would highly appreciate it if you could give your thoughts on how you would approach building such a UI with hyperbole.

That would be excellent. While I'm being a bit rigid trying to lead people to composable code, it's very possible I've overlooked some use-cases. Thanks

[adithyaov]

Have you read that section before?

Ah, no, I have not read it.

If you haven't, how can I direct people to read that documentation better?

That's an age-old problem - RTFM

That said, I think of hackage as API documentation and not tutorial/design documentation.
Having a blog post or a separate tutorial may help.
It's a big may because nobody RTFM :-)

---

The document that you linked to helped - thanks!

[seanhess]

Yeah, it's really hard to keep documentation in sync with the code. I'm happy with it in the source files for now, with hyperbole.live examples to supplement. Maybe one day it'll make sense to create a separate guide, but probably not until 1.0

[adithyaov]

@seanhess How often do you think a child component may want to talk to a parent component?

---

Currently, I can think of 2 ways how this can be possible:

1. Pass the parent action Refresh to the children's hyper views.
2. Use the JS layer to publish events from the child to the parents.

If parent-to-child communication is not generally used, then these (hacks?) methods are all you need.

[seanhess]

It comes up often enough when a child view needs to tell a parent to refresh a larger view. We definitely. need a way to address it. But you CAN do parent-child and child-parent communication, you just have to put them in the same module. I can't imagine a page so complicated that it won't fit in one module, if you're factoring views and handler code out to other modules. The hacks shouldn't be necessary.