Closed samthor closed 4 years ago
Thinking about this a bit more, I'm wondering if we might be able to go a simpler (and safer) route.
If we do client-side js then we'd likely only need to deploy the site two times: Once when the event starts (we could probably do this the day before the actual start date), and once more when the event ends.
We can go ahead and build these pages and even check them in. We just need to set them to permalink: false
so they don't get output.
Instead of using remote-config (which takes a while to load), we'd use client-side JS for the widgets to decide which iframe src to show for the livestream and chat. We could bootstrap the page with some JSON that contains all of the data that the event needs to power itself. Waiting on our JS to load may be a tad slower, but ultimately I think it's more reliable and easier to build and we can explore if there are ways to load it faster.
For sections of the page that remain the same across versions, we could consider putting them in njk includes so we don't have to keep the different versions in sync.
Another option would be to put everything in /live/index.njk and rely on conditionals to turn different sections on or off
(Happy to have better name suggestions due to the obvious ambiguity.)
Problem For WDL, our master page needs to, from a user point of view, go through a number of transitions during our upcoming event.
Proposal
fetch()
sees this as 200)Implications
Alternatives
Notes There'll be no unsupported browser solution. So if we're statically including an
<iframe>
for a video session and a YouTube-supporting-but-not-web.dev-supporting browser opens us, they'll have to reload.