Fullscreen Elm App in 0.19 (childNode issue) Reopened

Request Feedback
21

This is a problematic chrome extension:

You can try it with, for example:

https://elm-spa-example.netlify.com/

1 Like
22

I’ve tried this using one of my own Elm apps, and everything worked fine there. After investigating, I may have found an interesting work-around:

My app loads its main script asyncronously to avoid blocking. This means that I init() the Elm app as soon as the Javascript file got loaded, but the app will still wait on a subscription for all other resources (CSS, Fonts, etc.).

For context, my entire index.html looks like this:

<!doctype html>
<script type="application/javascript" src="/_js/frontend.js" async onload="require('src/frontend.js')"></script>
<meta http-equiv="X-UA-Compatible" content="IE-Edge">
<meta name="viewport" content="user-scalable=no, width=device-width, initial-scale=1, maximum-scale=1">
<link href="/_styles/frontend.css" rel="stylesheet" media="none" onload="media='all'">
<link href="/_styles/styles.css" rel="stylesheet" media="none" onload="media='all'">

This has the side effect that rendering any meaningful content is delayed by at least 1 frame while Elm is waiting for a ResourcesLoaded message (I just return Document "Loading..." [] from view until I get this message). This gives the Viber extension plenty of time to insert its cruft, and Elm will happily remove it afterwards, once it actually starts rendering.

23

So this would ultimately break the extensions instead of the Elm app? This isn’t a valid solution then. Regardless of how we feel about the practices of such extensions, users have them installed for a reason.

24

Regarding Aaron_White hack, it’s not enough. Elm replaces the node with a body element. I needed to patch another line. After that It’s seems to be working fine, including navigation.

25

Yes, you’re right, it does break the extension in some ways. I didn’t try it for long enough, unfortunately.

But I think there are still 2 important observations to draw from this:

  • I didn’t try to break the extension, I tried to load things fast. I would have probably broken it if I was using Javascript as well.
  • No one can actually “own” the contents of the body tag. The best thing we might be able to do is control a contiguous slice of its children. (See Evans reply)

Even then, I’m no longer that sure the solution Evan proposed would work in that case: You simply cannot know which elements of the body to replace (because of SSR), and which ones to keep (because a browser extension depends on them) as soon as you initialize your app after DOMContentLoaded, if you don’t want to break extensions like this.

Overall, I feel better about breaking a small number of extensions than breaking the whole website. As a user, I would also prefer a broken browser extension (which means I can’t share cute bunny pictures as easily) over a broken SPA (which means I can’t share and can’t look at pictures of cute bunnies).

I understand the problems of letting people specify a node for application or document programs, but it might be the only solution that will work in every case. Maybe we can add some additional requirements, like making sure the node is a direct child of <body>.

3 Likes
26

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.