Drupal8.x and Symfony – Asset Component: Part IV Series

Tonight I took a look at the Asset component. I was a bit reluctant because by the looks of it I thought of it being large, many files and folders. It has a lot of implementation specific classes and things relating to js that did not ring too much on the backend keyword.

However after spending some time on #irc channel #drupal-contribute I was aided by nod_ about the important efforts happening in Drupal currently. First of all I have to say there is one person that deserves a lot of attention and that is sdboyer. He had started the work of including Assetic way back almost more than a year ago. He has put so much work that after Robloach plugged assetic to the composer.json he, Sam, has been pounding it for so long that it is just outstanding. He has taken upon himself a very complex integration challenge.

Drupal is a mess in terms of assets. There are many things that range from the fact that its assets had a mechanism based on weights for being ordered, the business logic is a mess and procedural, it totally breaks encapsulation in early attempts to solve this problem, and more.

Sam explained all along well and there had been periods of time that he is so busy, almost months. He has however always come back to pound it like a pro.

So let’s explain this. Assetic, let’s take a look at the library and its basic usage (from the docu):

use Assetic\Asset\AssetCollection;
use Assetic\Asset\FileAsset;
use Assetic\Filter\Yui\JsCompressorFilter as YuiCompressorFilter;
$js = new AssetCollection(array(
    new FileAsset(__DIR__.'/jquery.js'),
    new FileAsset(__DIR__.'/application.js'),
), array(
    new YuiCompressorFilter('/path/to/yuicompressor.jar'),
header('Content-Type: application/js');
echo $js->dump();

And in the template:

<script src="/assets/javascripts.php"></script>

The concepts are very simple, you have a collection of assets which are dumpable resources, they take objectified resources and filters individually and collectively.

You dump it and voila!

Drupal situation however turns things a bit uglier, because Drupal does a lot more on top of just dumping some collections. Drupal handles the assets and assign them order, yeah it does matter in Drupal. As expected Drupal will try to reuse Assetic by wrapping the base classes and add what is lacking. Initially there were some attempts to hack into base classes by turning the properties protected instead of private, however the denial of this turned out to be better. Drupal now extends this class, well it is a long history and it is all recorder here in https://drupal.org/node/1762204.

I am not sure if the diff is based on patches or on sdboyer fork at this point but I created a diff on github here https://github.com/cordoval/drupal-1/pull/1/files. This is another problem for reviewing long work, they are including the composer.lock and what not which makes no sense. So I cleaned up and now the diff on github is more manageable and easier to review. I believe though the patch is the one that contains everything.

Long story short, I strongly believe in github flow because the latest diff is always the current diff and state of things. You add commits and that shows immediately and hides comments that were addressed already. You don’t have to review a 182 comment long page for just finding out what you want to work on. For such a work as this few people will actually collaborate and Github is way way better for this.

Anyway, going back to the topic, I am looking forward to Kriswallsmith’s talk on this topic on DrupalCon2014:

Screenshot 2014-05-26 02.14.51

I hope I don’t miss it and find out what is Assetic doing to plug best in Drupal.

The coming components to scrutinize are according to the image below on Symfony usage:


EventSubscriber and Routing!

Leave a Reply

Your email address will not be published. Required fields are marked *