Blueprints sidebar section for single-click Playground presets

[adamziel]

Motivation for the change, related issues

Adds the Blueprint Gallery to the Playground UI as a first-class feature.

Implementation

Sourcing the list of Blueprints

GitHub automation maintains a JSON index of all the Blueprints in the directory at https://raw.githubusercontent.com/WordPress/blueprints/trunk/index.json. This PR just sources that data and adds a DataView where it can be browsed.

It ships a new useFetch() React hook that makes the state management around fetch() easier. Maybe this simplistic hook will be enough, or maybe we'll quickly replace it with react-query or so. We'll see.

Fetch proxy for offline caching

This PR ships a "proxy" service worker route for offline caching of cross-origin requests.

Playground is now an offline-enabled PWA and anytime we rely on network resources, we must consider what happens when there's network connectivity.

For same-origin request, that's easy. We can just cache them in the fetch event handler in the service worker. However, that event handler won't handle cross-origin requests. Therefore, this PR ships a special same-origin /proxy/network-first-fetch/ route that can cache cross-origin requests in CacheStorage.

For example, the following request would fetch the list of all the Blueprints from the Blueprints directory:

https://playground.wordpress.net/proxy/network-first-fetch/https://raw.githubusercontent.com/WordPress/blueprints/trunk/index.json

The service worker would be notified, then it would strip the https://playground.wordpress.net/proxy/network-first-fetch/ prefix, and source the actual information from https://raw.githubusercontent.com/WordPress/blueprints/trunk/index.json. If the network is available, it will always request the fresh data. If the network is not available, it would source the data from CacheStorage if available.

Testing Instructions

Interact with the gallery, confirm it works in the offline mode, confirm the blueprints load without issues and that the rest of the UI works the same as before this PR.

Follow-up work

• Revisit the design based on user feedback and @jarekmorawski's explorations in Figma
• Integrate with the Blueprints builder when it's ready
• Add GitHub connection to make contributing Blueprints easy
• Integrate with the upcoming visual Blueprints builder

cc @brandonpayton @bgrgicak @mtias

[mtias]

Nice, this is cool

[bgrgicak]

This is great! Let's see with @jarekmorawski how to integrate it into the new UI.

Consider accepting Blueprint preview thumbnails in the directory

I don't think that we need this for v1. It's frequently hard to visualize a blueprint in an interesting way (examples add mu-plugin, install theme from git).

UX decision – should the "preview button" keep spinning new sites? Or should it kill the previous Blueprint preview?

I would keep it consistent with the rest of the UI. Clicking on preview should start that site on the right side of the sidebar. Ideally as a temporary site so that users can save it from the manage UI if they want to.

[adamziel]

I would keep it consistent with the rest of the UI. Clicking on preview should start that site on the right side of the sidebar. Ideally as a temporary site so that users can save it from the manage UI if they want to.

Right, but would clicking through 10 Blueprints leave me with 10 temporary sites? Or would it clean up those sites as I browse?

An idea: create a single temporary Playground called "Blueprint preview" and reset it with the last selected Blueprint every time.

[bgrgicak]

Right, but would clicking through 10 Blueprints leave me with 10 temporary sites? Or would it clean up those sites as I browse?

The temp site could be created when you expand the site, so if you are just clicking on items, they wouldn't be created.
But making it deliberate and offering the user a save button seems like a better choice.

This would also be useful for temporary sites in general.

[brandonpayton]

This is such a great idea.

An idea: create a single temporary Playground called "Blueprint preview" and reset it with the last selected Blueprint every time.

Since #1731 is keeping multiple temporary sites in-memory, this sounds like a good compromise to me. Perhaps we could create a separate temporary site (and notify the user) whenever they start interacting with "Blueprint preview". At that point, they aren't merely clicking through options but have started "trying things on".

[bgrgicak]

I'm wondering if using the blueprint gallery will be the best thing in the long term.

This section is technically Playground Apps. You go there and add a WordPress-based app to your Playground.

The Blueprint gallery is more about showing the technical capabilities of Playground while this could be much more.

Imagine going to Playground.WordPress.net or your locally installed PWA and seeing all your apps there.
You have a note-taking app built from the post editor and a search plugin.
You have a development environment, a collection of code, and SQL editing plugins.
You have a RSS reader for everything that you follow...

To get more apps you just go to the apps section and install more.
Submitting a new app is just writing a blueprint which anyone can do with the help of GPT and our documentation.

[asirota]

Can someone inspect the underlying json?

[bgrgicak]

Can someone inspect the underlying json?

@asirota I'm happy to help, please open new issue and share the file with us.

[asirota]

@bgrgicak sorry I wasn't more clear. I meant could there be a feature in this to inspect the json of the blueprint being previewed? Useful for learners.

[adamziel]

I'm wondering if using the blueprint gallery will be the best thing in the long term.
This section is technically Playground Apps. You go there and add a WordPress-based app to your Playground.
The Blueprint gallery is more about showing the technical capabilities of Playground while this could be much more.

To me, showcasing technical capabilities is just a convenient starting point for the Blueprints gallery. It can be both a source of demos and a source of powerful apps. Both use-cases require a central location, contributing workflows, integrations, ways of forking and remixing the Blueprints. Why split that in two places? Once we have powerful app-like Blueprints, we can just add a "features": true meta flag to show or hide then in the webapp.

Note all WordPress directories already work this way. There are demo themes like stacks, and there are powerful themes like TwentyTwentyFour. There are demo blocks and app-like block suites. There are demo plugins like hello-dolly or classic-editor, and there are app-like plugins such as WooCommerce.

And in an even longer term, we can propose Blueprints for WordPress core and it will already have an extensive Blueprints directory on day 1.

[bgrgicak]

To me, showcasing technical capabilities is just a convenient starting point for the Blueprints gallery. It can be both a source of demos and a source of powerful apps.

I agree, it's more about the naming, but I'm probably jumping 5 steps ahead.
We definitely first need some apps before we can start calling it like that.

[juanmaguitar]

Closing this related issue: #1463