Skip to content

Use a DisplayManager to handle the coordination of overlays #83

@rtshkmr

Description

@rtshkmr

Display Manager Skeleton

The intent of DislayManager is to be able to determine the following things:

  1. which layout (e.g. mobile vs desktop) to use (if we’re discriminating b/w device types)
  2. hold state about current app mode and other configurations about it.

It seems there are 2 choices when structuring things:

  1. We could keep the DM as a sibling of the other liveviews (MediaBridge, Written)
  2. DM could be a parent for the other liveviews under it, effectively being somethng like a “stateful layout”

Some questions:

  1. Are the user action buttons going to be another liveview or a livecomponent?
    • the only requirement is that, similar to the MediaBridge, stickiness is there even on page-reloads.
      For now, I shall keep the necessary state within the DM

Possible Steps:

  1. Nest existing extra liveviews within the DM, to create a parent-child r/s
    • quick POCs have shown that the pub-sub comms work regardless of how liveviews are nested, so this doesn’t affect the comms b/w these server-side components
  2. Add some dummy state in DM, let DM also know the type of device by receving an event from the client-side

Metadata

Metadata

Assignees

Labels

lift.highhigh lift issue -- may require some strategizing around itpriority.highHigh urgency, high impact -- Priority is the intersection of impact and urgency.type.refactorDeals with refactoring, typically with a better design in mind and should have a present/future pain

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions