Load client from playground.wordpress.net instead of @wp-playground/client

[ashfame]

@adamziel made the suggestion to use the client from playground.wordpress.net itself to have a version that’s always synchronized with the Playground version

[psrpinto]

I'm not sure I understand how this would work, could you clarify how we would use the client from playground.wordpress.net?

[ashfame]

Like this:

<iframe id="wp" style="width: 100%; height: 700px; border: 1px solid #000;"></iframe>

<script type="module">
    import { startPlaygroundWeb } from 'https://playground.wordpress.net/client/index.js';

try {
    const mountDescriptor = {
        device: {
            type: 'opfs',
            path: '/try-wp-zz',
        },
        mountpoint: '/wordpress',
    };

    const isWordPressInstalled = confirm('Is WordPress installed? Ok=yes; Cancel=no;');
	console.log( isWordPressInstalled ? 'WP: Already Installed' : 'WP: Not Installed' );

    const client = await startPlaygroundWeb({
        iframe: document.getElementById('wp'),
        remoteUrl: `https://playground.wordpress.net/remote.html`,
        mounts: [mountDescriptor],
        shouldInstallWordPress: ! isWordPressInstalled,
    });
    await client.isReady();
    window.pgclient = client;
} catch (error) {
    console.error("pg client", error);
}
</script>

[psrpinto]

Thanks for clarifying. This might might make it a little better, but I see some invonveniences:

• There would be no types
• The APIs can still change and our code would still need to be adapted. For example, if startPlaygroundWeb()'s API changes.
• We can't leverage debugging tools like git bisect because we can never be sure if something is broken due to changes in playground.wordpress.net.

I think ultimately, the best solution would be to package playground into the extension. If that's not possible, for reasons outside our control (e.g. browser limitations), another possibility would be for playground.wordpress.net to provide multiple versions, e.g. https://playground.wordpress.net/v0.1.2.

[ashfame]

Agree! Or we can host our own instance try-wp-playground.wordpress.net & control when to update it.

[adamziel]

The APIs can still change and our code would still need to be adapted. For example, if startPlaygroundWeb()'s API changes.

I want to avoid breaking changes in startPlaygroundWeb as it would affect all the apps integrating Playground. However, even assuming breaking changes, it doesn't matter where the client comes from as remote.html would also be affected.

For non-breaking changes, loading the client from playground.wordpress.net would actually keep the browser extension working – the client would be auto-updated in the same deployment as remote.html.

We can't leverage debugging tools like git bisect because we can never be sure if something is broken due to changes in playground.wordpress.net.

Isn't that true for any technique of importing the client?

There would be no types

Isn't there a way to configure TypeScript to still get types? Like an import map in tsconfig.json?

Agree! Or we can host our own instance try-wp-playground.wordpress.net & control when to update it.

Yup, that would work too. If you host it on the atomic platform, you should be able to just fork the Playground repo and reuse the same deployment scripts.

[psrpinto]

We can't leverage debugging tools like git bisect
Isn't that true for any technique of importing the client?

Sorry, I think my maybe comment above didn't make clear what I meant. The bisect comment related to a scenario where everything the extension needs to operate is bundled within the extension, and we control the exact versions of everything. In this scenario, once the user installed the extension, they would be able to turn off the network, and everything would still work. (To be clear I'm not saying that offline functionality is a feature we should care about, I'm just using it to illustrate the point).

In practice, this would mean that a specific version of Playground, along with a specific version of WordPress would be bundled into the extension. We would then reference the remote.htmlthat exists in the extension, and the WordPress assets would also be pulled from the extension.

I can see several advantages with such an approach:

• Playground loads faster because everything is already available in the user's machine
• Reduced bandwidth usage for the user
• Reduced traffic to playground.wordpress.net
• We control the exact versions of everything, which has the benefits of:
  • Providing a more stable experience to the user, since there would be no risk of new Playground or WordPress versions breaking something. (We have already experienced things breaking with the release of WP 6.7).
  • Whenever a new WordPress version releases, we can issue a new version of the extension that is guaranteed to work with the new WP version, and we could take the opportunity to also update Playground

We could still make it possible for the user to be on the "bleeding edge" if they so desire, through a setting, for example.

I don't know if bundling everything into the extension is technically feasible, but I think it would allow us to provide a more stable experience.

[adamziel]

Oh I would love a reusable setup for shipping Playground inside an extension in a way that works across web browsers.

It all depends on your apetite — it would likely take a few weeks to get it right and it may still require an external domain for the service worker.

Check out the "edit visually" browser extension from the playground-tools repo (and the PR exploring v2) for prior art.