There is a large and growing chunk of code that we inject into the preview frame to facilitate interaction with the main environment. The current approach of stringifying functions is unwieldy and error-prone.
Instead, make a new Webpack entry point that allows us to build a real bundle to use in the preview frame. We will then just load this bundle using a normal <script> tag. Using the service worker, we can make sure it’s already loaded and cached locally by the time it’s needed.
One question is how we’re going to get access to the hashed filename of the asset in production mode. It seems like this should be possible in principle (it’s basically the same thing the html-webpack-plugin does) but I’m not sure if there is existing tooling that makes it easy.
As part of this refactor, we should be able to make a few related improvements:
- Make SweetAlert a normal NPM dependency and load it accordingly
- Use jschannel or something like it to manage inter-frame communication—should allow us to cut down on a lot of the
postMessage boilerplate we’ve got right now
There is a large and growing chunk of code that we inject into the preview frame to facilitate interaction with the main environment. The current approach of stringifying functions is unwieldy and error-prone.
Instead, make a new Webpack entry point that allows us to build a real bundle to use in the preview frame. We will then just load this bundle using a normal
<script>tag. Using the service worker, we can make sure it’s already loaded and cached locally by the time it’s needed.One question is how we’re going to get access to the hashed filename of the asset in production mode. It seems like this should be possible in principle (it’s basically the same thing the
html-webpack-plugindoes) but I’m not sure if there is existing tooling that makes it easy.As part of this refactor, we should be able to make a few related improvements:
postMessageboilerplate we’ve got right now