Establish App lifecycle as the only way to start rendering

[MaxDesiatov]

The reasoning here is that the only way to start rendering should be through creating an App type and calling main() on it. This would allow us to remove the View-based DOMRenderer initializer and also thread the type of App through DOMRenderer and StackReconciler through generics without erasing it with _AnyApp. Then potentially we could remove _AnyApp and the indirection it requires altogether. _AnyApp is not present in the upstream API anyway 🤔

What do you think @carson-katri @j-f1?

[carson-katri]

Yeah, this makes sense to me.

[j-f1]

It depends on if we want people to be able to incrementally adopt Tokamak. I think it’s perfectly fine to say that you have to write the entire app in Tokamak (or at least the root of the app), but it should be an explicit thing we document.

[carson-katri]

I think you would still be able to do that, but you’d have to define the tokamak part of your site with App at the root.

[MaxDesiatov]

@j-f1 Excellent point, and I'm not sure I'm ready to commit to that yet myself, unless there's a strong pressure to do that.

[MaxDesiatov]

Removing the View entrypoint of DOMRenderer would preclude you from rewriting incremenetally in multiple places in an SPA at the same time. As in, the assumption everywhere that we have a single mounted App instance and a single renderer, at least for the DOMRenderer. We do allow multiple scenes though, maybe we could introduce a custom scene type, so that you still create a single app, but attach multiple disconnected scenes in multiple places? No idea how well that would work in practice.

[MaxDesiatov]

Scratch that custom scene suggestion, I probably would prefer something like:

extension App {
  func _render(in: JSObjectRef) {
    // ...
  }
}

There you'd call attach on your app passing it a reference to the DOM element you'd like to render in.

This would need to set up multiple instances of DOMRenderer I think, so we have to make sure we don't have any disruptive singleton-like behavior anywhere.

[j-f1]

I do think the custom scene type might be worth exploring since there aren’t any other uses for multiple scenes atm

[MaxDesiatov]

I'm not sure how you'd schedule at what moment those scenes are displayed. Say you have a big React app with hundreds of components and you want to to rewrite it incrementally, but you'd probably proceed in different branches of the big component tree, even if sequentially. It would be hard to connect those different branches with scenes, especially if those different branches are not displayed at the same time. Maybe those component branches are on different "pages" and these "pages" are displayed separately. I'm not sure how to map that well to the scenes API, the App._render(in:) API seems more suitable for this scenario, but maybe there's something I'm missing.

[j-f1]

That makes sense.

[carson-katri]

Maybe it could work with Scene, where you have a DOMScene type, which provides its host node, and it can take a scene as the child. You could then have one DOMScene for each part of your app you're replacing:

struct ProfileScene: Scene {
  var body: some Scene {
    DOMScene(node: { ... }) {
      WindowGroup { ... }
    }
  }
}

struct SearchScene: Scene {
  var body: some Scene {
    DOMScene(node: { ... }) {
      WindowGroup { ... }
    }
  }
}

struct Reddit: App {
  var body: some Scene {
    ProfileScene()
    SearchScene()
  }
}

Where DOMScene is something like:

struct DOMScene<Content: Scene>: Scene {
  let body: Content
  let nodeQuery: () -> JSObjectRef?

  init(node nodeQuery: () -> JSObjectRef?, @SceneBuilder body: Content) { ... }
  init(id: String, @SceneBuilder body: Content) { ... }
}

Then when App goes to mount the scenes, it can attempt to find the node with the nodeQuery function, and if it exists it computes the body of the DOMScene and puts it in the host node. We could use the MutationObserver API to be notified when the element has been added, and rerun the nodeQuery to check if the element exists yet.