support multiple livesockets

[gfrancischelli]

What

Add rootViewSelector option to liveSocket constructor to scope which HTML nodes this liveSocket should connect.

Why

To allow multiple liveSockets in the same page, each pointing to a different domain. The motivation is enabling a microfrontend-like architecture, making it possible for different teams working on different components to have complete deployability isolation.

[josevalim]

Should this be inversed, so people could do #foo-baras the root view selector if they want to? In such cases, should they end it with a space?

[gfrancischelli]

I was thinking it would simplify things if we just ignore the PHX_VIEW_SELECTOR and only use the user-defined selector?

The initial idea behind composing both together was because I didn't notice we could customise the container of the LiveView. So my initial implementation had something like: :has(.some-class-inside-the-lv-template).

[gfrancischelli]

Any reason not to just replace PHX_VIEW_SELECTOR completely with a user defined selector?

new LiveSocket("/live", Socket, {params: {viewSelector: ".my-selector"}})

We can document users need to customise the LiveView :container in that case. It can be done globally in use MyAppWeb, :liveview or easily extend to accept as param use MyAppWeb.LiveView, :liveview, app: :something 🤔

[josevalim]

I think that would be my vote but we need to tell people they will want to check for [data-phx-session] unless their selector points directly to the LiveView container.

[victor23k]

Hi! I was actually starting to work on the same issue, though the motivation in our case is to embed LiveView apps in multiple third party sites. This PR solves the problem of sending events to all connected sockets. We also identified a couple more nice to have features:

• Dispatch event on socket disconnection in the client side. This would allow doing an operation like hiding the rootViewElement.
• Set an element id prefix per LiveView to ensure unique element ids.
  Example: the <.flash_group> component id will clash with other LiveViews that also use this component with the default id.

@gfrancischelli This is great work! Do you share the need to have any of these?

@josevalim Do you think these proposals make sense? Would you be open to PRs?

[SteffenDE]

@victor23k my gut feeling is that embedding LiveView apps would be better handled using iframes, having only the minimal code on the third party's side for gluing things together.
If you directly embed into a third-party's page, you're always working in an environment you don't fully control, duplicate IDs being a good example. Those also would not be a problem when using iframes.

[gfrancischelli]

@victor23k thanks ❤️! I'm very happy to see there's more people needing this.

My use cases are:

• Microfrontend architecture without the hassle of iframes
• Incremental migration of legacy JavaScript web apps

Dispatch event on socket disconnection in the client side.

I'm not sure if I get it, and I don't have this use case (for now), but you can use this callback liveSocket.socket.onClose?

Set an element id prefix per LiveView to ensure unique element ids.

We didn't face collisions like this yet 🤔

[gfrancischelli]

@SteffenDE For the microfrontend use case, we are trying to avoid an iFrame based solution with this.

Anyway, thank you for the great work in testing the JS part of LiveView ❤️ Do you have suggestions what else should I look to test in this PR?

[SteffenDE]

@gfrancischelli I'm not criticising your microfrontend approach. I think it's fine to do this when you are in control of the overall page, I'm just not sure if I would do this on third party sites.

Thank you for the kind words! I didn't have the time to look into your changes in detail, but I'll come back to you in the next couple of days :)

[victor23k]

@SteffenDE thanks for your suggestion! will look into that.
@gfrancischelli I'll stop hijacking your PR comments now 😅, also thanks for the tip on the callback