Problem/Motivation
I have a few concerns around the implementation of the UI, especially for the time needed to push the current UI though the core gates.
Currently the list of projects is displayed though a svelte app. Here are a few things that concerns me. Some things are trivial, others not so much, in no particular order:
- Svelte dependencies have not been looked over for core inclusion
- the pattern to use svelte does not exist in core
- the commit checks are not set up to handle svelte files
- The svelte app is reimplementing existing patterns with enough differences to see it's different from the rest of core for: modals, pagination, list filters.
I think all those things will make it quite hard to get PB past the core gates and into core.
Additionally the advantages of doing a svelte app are not clear. There are very few people that contributed to the svelte codebase I count 9 people from the commit logs with credit for the svelte codebase. Most of the code has been written by
grasmash →
and very little has changed since it was made in june 2021. It is not clear who will be willing to maintain this code once it gets into core.
Given the above it seems like the implementation of the UI will take a very significant amount of work to get in core and subsequent changes will be hard to ship.
Apart from that introducing a whole new way of rendering content in Drupal will raise a few questions that I think will be blockers for core inclusion:
- How to translate strings in the svelte app?
- What is the expected customazibility of the project cards? (can a vendor add a custom stamp on module they have explicitly vetted for their customer, if yes, how?)
- How are the filters/sorting options customizable?
- Changing any of the above means there is a need to recompile the svelte app?
Proposed resolution
I'd like to decouple the PB with the svelte topic in order to get a faster path to core commit.
We could make use of all the existing tools we have in core to provide a decent UI that will be much easier to get in core and with tools that people and contrib devs are familiar with.
Essentially I'm proposing to use views to provide the listing page. The ajax version of a views with exposed filters is good enough to provide a basic interface. As long as we provide ample API and documentation on how to use those api to create a custom version of the PB contrib will be able to do it's thing, like what happened with toolbar, module filter, gin, etc.
Remaining tasks
- ✅ File an issue about this project
- ☐ Addition/Change/Update/Fix to this project
- ☐ Testing to ensure no regression
- ☐ Automated unit/functional testing coverage
- ☐ Developer Documentation support on feature change/addition
- ☐ User Guide Documentation support on feature change/addition
- ☐ Code review from 1 Drupal core team member
- ☐ Full testing and approval
- ☐ Credit contributors
- ☐ Review with the product owner
- ☐ Release