Create a "mini-browser" UI

Are we referring to the mockups from this Starshot issue: #3449347: [META] Recipes, Package Manager and Project Browser improvements needed for Drupal Starshot → ?

Yup! The first one is for the "site template" version and the second is for the "feature-based" one - and we're prioritizing the "feature-based" one first.

Hi @Ravi Kant,
Thanks for considering this project. We are going to maintain the theme, so currently, we don't need new maintainers for this theme.

yash.rode → made their first commit to this issue’s fork.

Gave this a quick manual test. It worked, but there were a few things I noticed:

• The styling is virtually nonexistent (see screenshot). It can probably be deferred to a follow-up, but it's ugly the way it currently is.
• There's no text or anything that indicates what this little list of projects is, or what to do with it. Ideally, we'd add a configuration option to the block which allowed us to set some preamble text.
• If you click to a project's detail page, "back to browse" takes you back to the main project browser, rather than where you were. That's jarring.
• There's no indication that a project browser is loading in the block's spot. This is something we'd ideally fix for all project browsers; it'd be good to have some sort of throbber there while it loads.

I think these are all follow-up material, though.

Let me preface this comment by saying that nothing I am about to say is meant to impugn any work that was done by Yash, myself, or anyone else who worked on this. My problems here are with the management, not the technical side.

Having said that...what are we doing here?

When I manually tested this issue, I saw a small project browser displayed in a block, exactly as promised. So it does what it sets out to do...but how is it useful? What problem is this mini-browser solving?

I am hard-pressed to figure out what a non-technical user is supposed to make of this thing. They will see several icons, and some words that are most likely meaningless to them. One of those things will be freaking Chaos tools, which should never be seen by a non-technical person under any circumstances.

I think this was implemented without a clear idea of who it was meant for, or how it would be used, or what the benefit to end users would be. We need to take this back to the drawing board and figure out what we're trying to achieve. This is a case, I think, of incomplete wireframes (Drupal CMS's, to be precise) dictating the implementation, rather than a fully thought-out user experience being brought to life.

Postponing until we have more info from the UX team.

Agree this should be postponed for now. We may have a need for something along these lines to expose local recipes post-install, but we are best off waiting for wireframes before we continue.

The main reason for this issue's existence was to support the Starshot wireframes Dries presented, which showed a way to apply recipes during the installer. Since that was abandoned in favor of a post-install recipe-chooser, and that was largely handled in ✨ Expose each source plugin at its own dedicated route Active , can this issue be closed? I don't think there's a need for this specifically; or, at best, we re-scope this issue for whatever the next logical choice is for the post-install thing. However, I think that might be handled in Recipes initiative and not here in PB.

Setting this as a target per our discussion earlier. Updated IS with the dashboard design.

penyaskito → changed the visibility of the branch 3450629-create-a-mini-browser to hidden.

I tried to rebase the latest PR but had no luck, too outdated and I wasn't following that closely.
My svelte foo is none. But with the available docs for handling svelte in project_browser I got really close.

I think we still need a block providing a curated set of 3 local recipes to install.
That block is designed to be on the Welcome dashboard.

With that block:

• Should the install happen on the dashboard itself? Not sure.
• Should it follow the "add to cart" pattern? My guess is not, as you only have 3 recipes to install.

I think I might be able to give this is a try if someone helps with the rebase, or if I start from scratch a new MR.

We have designs now of what we're shooting for - we'll see if we can help C with the rebase!

I strongly suggest we hold off on this for a bit.

I think there are a few blockers we need to resolve. Firstly, we don't want to have the number of projects (and other display options) be global constants; they should be instance-specific. That means we'll need to change some stuff in the Svelte to accommodate that. We also need to ensure filters are handled generically (we're almost there, but Search is still a global thing), so that we can disable filtering in the mini-browser instances.

These things need to happen (are happening) in other issues.

Proceed if you want, @lostcarpark, but be aware that this will likely take a while and undergo significant refactoring (possibly a rewrite) once Project Browser's underlying architecture is actually ready for this. We're not there yet. But we will be.

There's some work done here- but lots of design questions still need to be answered. Per @phenaproxima in Slack:

I know that the designs exist, but they haven’t been fully thought through. Example — if you say “only show 3 projects”, that beggars the question of which three projects to show. Just whichever the top three are? By what sort criterion? Can/should they be curated? These decisions need to be made beforehand.

And if, to continue speculating, the projects can/should be curated — then we have to have infrastructure for that. Source plugins aren’t configurable at all yet. I have no idea how any of that would work for, or be presented to, a site admin. And it’s unclear how _installing_ projects via multiple mini-browsers would work; the Svelte code isn’t ready for that. All of this needs to be sorted out.

Discussed this with @lostcarpark in Slack.

We agreed to reduce the scope of this issue to just:

• Create a block that exposes a project browser.
• Allow the block to limit the number of items visible in the project browser, via its configuration.

All the display stuff will remain unchanged -- projects will still show logos, categories, and all that jazz. The project browsers will show filters, pagination, sorting, and the other chrome. In the interest of not introducing messiness or technical debt (especially now that alpha10 is finally far more cleaned up than it was even a couple of releases ago), we'll deal with those things in follow-up issues, since it does make sense that we'd want to remove the chrome and certain aspects of the projects (like the logos) in some situations.

How to choose which projects are displayed is also something best handled in its own issue. For now, the mini-browser blocks will just show whatever the full project browser would, just not as much of it.

I think it should be straightforward to strip out the parts that don't fit in the new scope. I will aim to get that done soon.

As I consider the implementation here, I think we should probably revert all front-end changes and make the sources respect a limit key in their plugin configuration, to limit the number of results.

Then all the mini_browser block has to do is forward the configuration settings to the source plugin and let it do the right thing. There is some nuance here that's hard to explain...

Given that most of the "minification" of the project browser will happen in ✨ Allow the frontend code to be initialized with a preconfigured query Active , I think we can tighten the scope here.

This issue should only expose a block that lets you place a project browser anywhere. It'll be a full-sized project browser, so there's no concept of "mini". The ability to minify it will come later.

Think I have most of the changes needed done. I'm having a problem with the test (renamed to ProjectBrowserBlockTest), which passes when I run locally, but fails in the CI.

lostcarpark → changed the visibility of the branch 3450629-mini-browser to hidden.

I think I've made the changes suggested by @phenaproxima. Tests are passing, though I think we will need more tests on the browser block.

Moving to needs review to see what comes out of it.

This is really close, just a few points of cleanup. We probably also need to add test coverage for the case where the block is referring to a source that has been disabled (it should simply hide the block).

I think I've taken care of these now.

Well this is great! It's tightly scoped, clear as a bell, and has test coverage. I found a couple of minor things and some missing test coverage but this is really not far away from a hearty RTBC.

I have added test cases for block access.

testProjectBrowserBlockAccessWhenDisabled tests the black is initially visible, then updates the project browser settings so no sources are enabled, and verifies block is no longer visible. Is the $this->rebuild() after the settings change correct?

testProjectBrowserBlockAccessNonPrivileged tests that the block is visible for the admin user, then creates an unprivileged user, and checks it is not visible for them.

Just one question on code review.

Has test coverage, and tested manually and works like a charm.

Attached screenshot of the preview mode. Before that, the spinning never stopped until refreshing the page.

Saving credit

Merged !733 🎉