🇬🇧United Kingdom @hugronaphor

BramDriesen → credited hugronaphor → .

Glad to hear there is a consensus that existing approaches to handle ajax are outdated and not DX friendly.
This is the exact reason why a while ago when I needed to build an SPA-like app, I needed something more mature and modern.

I did look at that time at htmx but it felt to me that it's not the right solution to use especially that I have found out about Livewire. As a result I have ported it to Drupal as Wire.

The main benefit is that it's architecture has been tested and iterated for years already by Laravel community and it can handle any task mentioned here including form submissions, reacting/emitting events, web-socket, ... in fact Symfony ecosystem got their own Livewire inspired Live Components

To be clear, I'm not saying that I want my Wire in core instead of playing with htmx but I think we should look at the scope broader and consider something in between Wire and Symfony's Live components. Huge benefit on top of being able to create dynamic interfaces with ease, Laravel and Symfony developers would have a familiar tool in Drupal's core.

If we're talking about work in #6, suggested "Focal Point crop by height only" is not right but the opposite: "Focal Point crop by width only" (In patch: Focal Point Crop by Width)

Yeah, good catch.
Committed and released to 3.0.0-rc5

Closing as overriding library discovery Cache ID does give a way to achieve what has been asked.

@catch OK, fair enough hook_page_attachments_alter() does achieve what I was asking. Thank you for this.

I'll go one step further with another example:

function HOOK_library_info_alter(array &$libraries, $module) {
  if ($module == 'core' && !Drupal::currentUser()->isAuthenticated()) {
    $libraries = [];
  }
}

I understand that this might be unethical to do but I'm in a situation, where my app can live without Drupal and related JS objects.
I would want to remove everything because of performance and because the internet crawlers can detect the Drupal backend based on these JS objects.

Talking about Drupal's composability, I feel like there should be a way to not include Drupal assets.

For now, looks like decorating LibraryDiscoveryCollector is the way to do it as described in https://drupal.stackexchange.com/a/276800/13633

_nod you're right. Bad example from my side. I was trying to be generic...

Let's look at "system.libraries.yml" in "system" module. The "system/base" library is attached via "system_page_attachments()" on every page while what I'm trying to achieve is to only serve this library for authenticated users only and not anonymous users.

If attempting to conditionally remove the library as bellow, after clearing the cache via cli and visiting a page as authenticated user first, subsequent request to a page as an anonymous user, all assets of "system/base" would still be served.

function HOOK_library_info_alter(&$libraries, $extension): void {

  iif (!Drupal::currentUser()->isAuthenticated()) {
    if ($extension === 'system') {
      unset($libraries['base']);
    }
  }

}

So, adding access requirements to libraries is a way i was thinking this can be tackled.

Don't think I've been understood here.
I might have confused you by relating to aggregation but let's take out of equation the aggregation completely.

What I'm saying is that Drupal core and it's modules comes with a bunch of its libraries which in my case, non-admin users make no usage of them because Tailwindcss and AlpineJS is used.

Drupal allows you to unset libraries completely but not conditionally while what I would want to achieve is e.g:

if user has permission to use toolbar, serve the toolbar related libraries if not, there is no need for any of those.

Basically, I would want to be able to declare access requirements similar to how we define routes on library level, e.g:

toolbar:
  version: VERSION
  js:
    # Core.
    js/toolbar.js: {}
    # ...
  css:
    component:
      css/toolbar.module.css: {}
    theme:
      css/toolbar.theme.css: {}
      css/toolbar.icons.theme.css: {}
  dependencies:
    - core/jquery
    - core/drupal
    # ...
  requirements:
    _permission: 'access toolbar'

hugronaphor → created an issue.

hugronaphor → created an issue.

Released in 2.0.0-beta1

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

Edge-case:

I have 0, 1 or 2 entities to load and the order matters in my case.
For performance reasons I want to load them `loadMultiple()`

$nodeIds = [
  $queryPrev->execute()->fetchField(),
  $queryNext->execute()->fetchField(),
];
$nodes = $this->entityTypeManager->getStorage('node')->loadMultiple($nodeIds);
return [
  '#prev' => !empty($nodes[$nodeIds[0]]) ? $nodes[$nodeIds[0]] : NULL,
  '#next' => !empty($nodes[$nodeIds[1]]) ? $nodes[$nodeIds[1]] : NULL,
];

To avoid the warning you need extensive logic. E.g:

if (count(array_filter($nodeIds)) === 2) {
  $nodes = $this->entityTypeManager->getStorage('node')->loadMultiple($nodeIds);
}
elseif (!empty($nodeIds[0])) {
  $nodes = [
    $this->entityTypeManager->getStorage('node')->load($nodeIds[0]),
    NULL,
  ];
}
elseif (!empty($nodeIds[1])) {
  $nodes = [
    NULL,
    $this->entityTypeManager->getStorage('node')->load($nodeIds[1]),
  ];
}

But if you would have 3, 4, 5 entities to load multiple single loads would be needed.

I'm not demanding changes, just wanted to point out to this DX

No. No plans to provide any support for it.

hugronaphor → created an issue.

As per definition in the settings.php

$db = \Drupal\Core\Database\Database::getConnection('default', 'migrate');

Much needed fix for me.

My commands were taking at least 15 minutes to run after enabling LinkIt

Acknowledged
😔

Makes total sense.
Definitely skipped this when re-writting without JQuery.

Committed and available in new RC3 →

Thank you

Thanks.
Included 3.0.0-rc2 →