Decouple modality from modal visual treatment

[rjrjr]

@bencochran @zach-klippenstein @AquaGeek @dhavalshreyas

I had a chat last week with @helios175, and he schooled me on decoupling modal visual style from layering.

e.g., in Kotlin right now we have a number of samples where the top level rendering type is something like…

AlertContainerScreen<CardContainerScreen<BackstackScreen<Any>>

That is, you can show alerts over cards. Not so bad. But in our prodution app, where we have both a number of modal layers and a number of modal styles, the combinatorics get kind of nuts, something like:

typealias Root =
    AlertContainerScreen<
        TutorialBarsContainerScreen<
            CardContainerScreen<
                SheetContainerScreen<
                    CardContainerScreen<Any, Any>,
                    Any
                    >,
                Any
                >
            >
        >

because we want

• alerts to be modal over the tutorial bars
• tutorial bars to be outside the area covered by cards and sheets
• the ability to put sheets over cards visually, but then sometimes another card on top of that

Instead of this, the "big idea" (probably obvious to anyone who isn't me) is to have a single container type that is able to make things modal, wrapping others that own the visual style. This works because our modal screens already hold lists to allow visual stacking.

So the above would reduce to something like:

typealias Root =
    ModalContainerScreen<
        TutorialBarsContainerScreen<
            ModalContainerScreen<Any, Any>
            >,
        Any
        >

With AlertModal<T>, CardModal<T>, SheetModal<T>, BottomSheetModal<T>, etc., as possible contituents. If I want to show an alert over a card over a sheet, my root workflow assembles the equivalent of:

ModalContainerScreen(
  modals = listOf(AlertModal(...)),
  body = TutorialBarsContainerScreen(
    ModalContainerScreen(
      modals = listOf(
        SheetModal(...), CardModal(...)
      )
      body = ...
    )
  )
)

The downside here is that some layering rules become slightly more runtime. E.g. we don't want every child workflow that may want to show modals to have to know anything about tutorials, or these layering rules. An inner workflow should be able to render something like:

ModalContainerScreen(
  modals = listOf(CardModal(...), AlertModal("Are you sure?", ...)),
  body = ...
)

So some tutorial-aware outer workflow will need to filter the modals lists of its children, and move AlertModal instances to an outer layer. But that doesn't seem like a big deal.

Anyway, I'm giving myself permission to play with this today because I need to solve a problem where I'm getting double-darkness when showing cards over cards.

WDYT?

[bencochran]

I’ve been leaning in this direction in things I’ve been working on lately.

One nice side-effect of it is other changes can happen at “runtime” too, for example: on tablet-sized devices we want some modal content to slide-over from the edge of the screen (what Dashboard web internally calls a “blade” today) but on phone-sized screens we want that to be a full-screen presentation. In my current modeling, the “inner” workflow specifies the target style for a modal like you’ve described, but the container itself can use the environment to decide to use a different presentation style (also the presentation style is added to the environment of the content for view-side internal styling that that content might need).

[rjrjr]

Maybe at the same time we can adopt these interfaces for our renderings, to get a bit closer to what Swift did to banish ViewRegistry:

interface ViewRendering {
  fun buildView(
    viewEnvironment: ViewEnvironment,
    context: Context,
    container: ViewGroup? = null
  ) = viewEnvironment[ViewRegistry].buildView(this, context, container)
}

interface ModalRendering {
  fun buildDialog(
    viewEnvironment: ViewEnvironment
  ) : StealDialogRunnerInterfaceFromHelios = andADefaultImplementationToo()
}

[rjrjr]

Or even:

interface ViewRendering {
  fun asViewFactory(
    viewEnvironment: ViewEnvironment
  ) = viewEnvironment[ViewRegistry].getFactoryFor(this)
}

interface ModalRendering {
  fun asDialogRunner(
    viewEnvironment: ViewEnvironment
  ) : StealDialogRunnerInterfaceFromHelios = andADefaultImplementationToo()
}

[rjrjr]

With these conventions, a lot of our SomeContainer<T: Any> types can be a bit more strict, and self documenting.

class BackStackScreen<StackedT : ViewRendering>(
  bottom: StackedT,
  rest: List<StackedT>
)

class ModalContainerScreen<BodyT: ViewRendering>(
  body: BodyT,
  modals: List<ModalRendering>
)

[rjrjr]

Anyway: the reason for the ViewRendering / ModalRendering tangent is because I need some kind of hook for building dialogs, similar to ViewFactory. It's not just a tangent.

[rjrjr]

Fair warning: this ticket is only going to get more stream of consciousness.

Realizing that the DialogRef object in ModalContainer could be replaced with tags on Window.decorView. Meaning that we can create a set of extensions on Dialog just like those on View -- Dialog.canShowRendering, Dialog.showRendering, etc.

So, should be able to have ViewRegistry manage DialogFactory instances just like it manages ViewFactory.

Should also be able to refine View.showRendering et al to require the ViewRendering interface, and likewise for these Dialog extensions and a ModalRendering interface.

[rjrjr]

Could just make ViewRendering and ModalRendering marker interfaces, and separately give them asViewFactory() and asDialogFactory() extensions. Even closer to the Swift pattern, and cannot be abused by making renderings implement those methods directly.

That's pretty much what we're doing internally already. It's caused some confusion there, but I think mainly due to a bad interface name and a bad initial implementation of the extension method.

[rjrjr]

@WorkflowUiExperimentalApi
interface ViewRendering<RenderT : ViewRendering<RenderT>>

@WorkflowUiExperimentalApi
fun <RenderT: ViewRendering<RenderT>> RenderT.asViewFactory(
    env: ViewEnvironment
  ): ViewFactory<RenderT> = env[ViewRegistry].getFactoryFor(this::class)

[rjrjr]

And its close friend:

@WorkflowUiExperimentalApi
interface ModalRendering<RenderT : ModalRendering<RenderT>>

@WorkflowUiExperimentalApi
fun <RenderT: ModalRendering<RenderT>> RenderT.asDialogFactory(
    env: ViewEnvironment
  ): DialogFactory<RenderT> = env[ViewRegistry].getDialogFactoryFor(this::class)

Perhaps we also get rid of the buildView and buildDialog extensions on ViewRegistry. Or rather, make them RenderT extensions instead of these asFooFactory extensions. Back to the first sketch above.

[rjrjr]

And make WorkflowViewStub work in terms of ViewRendering. Don't think there's a WorkflowViewStub analog to ModalRendering, but that's fine. Or rather, that analog is a non-abstract replacement for ModalContainer.