Future plans for Pattern Lab 3

[philwolstenholme]

Hi @aleksip, this is more of an enquiry than a bug.

Thank you for all your work on this module, I use it really heavily at work, mostly for the Attributes object but also for referencing patterns inside other patterns as example data.

What are your thoughts about the future of the plugin with Pattern Lab 3's switch to Node? I don't fully understand the implications but presumably this will make it harder to run Drupal code inside PL? Or could plugins run PHP code in the same way as Pattern Lab itself will run Twig via PHP rather than JS?

[aleksip]

Hi @philwolstenholme, thanks, it has been really nice to see how this plugin has been useful for so many.

This question has been asked on Drupaltwig Slack as well, and I have started to investigate the possiblity of a Node version of Data Transform Plugin.

However, as exciting as it is, Pattern Lab 3 is still a bit rough around the edges, especially regarding plugins. Also, the current PHP Twig engine and rendering implementation do not seem to enable the kind of data sharing between JavaScript and PHP that would most likely be required by Data Transform Plugin.

I have opened related issues in the Pattern Lab Node repo, including a Data Transform Plugin specific meta issue.

So it looks like it will still take some time before the Node version of Pattern Lab will be able to fully replace the PHP version, at least from a feature parity/backwards compatibility point of view.

[philwolstenholme]

Thanks for the update @aleksip, much appreciated!

[aleksip]

Actually, let's keep this issue open in case there are other people wondering about this! I can also add future status updates here.

It is possible that it won't even be worth it to pursue a Node version of Data Transform Plugin. Folks who have already migrated to Pattern Lab 3 seem to be using Pattern Lab specific Twig demo templates instead of data files, and this approach seems to work well or even better. And avoiding Attribute in component templates is a good practice until it is made independent of Drupal core (actually I'd love to see Attribute made a part of Twig itself).

[philwolstenholme]

And avoiding Attribute in component templates is a good practice until it is made independent of Drupal core

I know this in my heart to be true, but it's just so damn useful! Our PL files are absolutely full of Attribute usage. Bringing it or something like it into Twig would be wonderful, but #2664570 on Drupal.org looks promising too.

[aleksip]

I know this in my heart to be true, but it's just so damn useful!

I know! 😄

I have adopted a middle road, where I use Attribute variables as classes in presenter (Drupal) templates and as strings in component templates. Such strings would be odd to have on their own, so it is not a perfect solution, but it works.

[kentr]

@aleksip Looking under the hood, it seems that Pattern Lab 3.x is a wrapper around a PHP twig renderer.

So, node passes a JSON data object to a PHP subprocess, and the Twig rendering is done in PHP.

So, I think the best place for this data transformation to happen is in the PHP render pipeline, like right before the call to Twig_Environment::render().

It would work if the PHP Pattern Lab event dispatcher & listeners are ported to @basalt/twig-renderer.