Getting PageModel from component delegate

Module Development
1

In a component model delegate, how safe is:

val pageModel = component.page as PageModel

?

Am I correct in assuming it’ll either be a PageModel or a DesignerPageModel?

2

ComponentModel doesn't have page, as shown here:

And the ViewModel's getPage() method returns a Page Interface. Which isn't assured to be PageModel.

I'd test it.

3

PerspectiveElement defines getPage(): Page?.

What do you need from PageModel that you don't get from Page? I can tell you that right now there's only PageModel and DesignerPageModel, and the latter directly extends the former, and I don't imagine that changing anytime soon, but :man_shrugging:

4

I want to tell a page to pre-emptively start a view from within my ComponentModelDelegate, instead of waiting for the client to send a view-start message. That way the view is already ready to go (with starting parameters) by the time the client requests it.

So basically I want to poke at the receive method and the Handlers class.

5

I think it's got legs...

6 Likes
6

It doesn't seem to cause any problems with deeply nested views (as long as you do a good job of keeping track of your mountPaths, lol).

In this example, an input parameter (random UUID) is being passed down from the root into 6 nested views (Nesting 1 - 5, + the card at the end).

4 Likes
7

image
image496×272 31.3 KB

The Magic

  1. View instances properties are linked together through gateway-side subscriptions. The native flex repeater uses the client stores to pass parameters around, which is the lag you see in the demo (each additional layer requires an additional ping-pong). The FlexRepeater+ requires no back and forth.

  2. Views are preemptively started on the gateway, then joined by the client. This required silencing the view-start message sent by the viewStore on startup, and replacing it with a new delegate-handled view-join message that doesn't try and restart running views.

Seems stable, but I really have no idea what larger implications this approach has. Please help me break it.

Embr-Periscope-0.3.0.modl (1.9 MB)

4 Likes
8

I think this is an amazing improvement.

I'm unfortunately not familiar enough with everything module-related, but you mention that everything happens on the gateway. Does that mean there is a higher load on the gateway than without using your module or not ?

Thanks !

9

Yes, the gateway does have to drive everything. But ultimately I’d argue this approach is not doing much extra work, this just changes when the work is done.

Like you’re always going to need to start/load views, and you’re always going to need to respond to property sync messages. This module just does that work preemptively.

That being said, right now this component 100% does more work than it needs to. It’s not very smart about when it recreates subscriptions and when it writes into the child view params tree, basically anytime the instances prop changes ALL children are updated. But there’s no reason it has to be this way, I just need time to make it suck less (make it work, then make it good).

Edit: Also just realized there’s absolutely no care given to whether a views parameters are configured as inputs or outputs :man_shrugging:t2:

7 Likes