Polishing the pulsar
Let me tell you something, pendejo, by the time you’re reading this Pulsar version 3.0.0 should’ve been tagged and released and it was very cathartic. After using Pulsar in anger on the MoJ and Q projects for the best part of two years we learnt a hell of a lot about what it takes to write a UI framework that needs to work across multiple products and now I’m taking the time to fix and polish up a lot of things before we start to FINALLY bring Pulsar into Jadu CMS.
Originally, this blog was only ever meant to be available internally at Jadu, so there’s a lot of inside baseball here and I apologise. In the future I hope to write more about our process, how we’re building our user interface platform and how we’re changing everything to make sure our software is beautiful to use, as well as great to look at.
Originally, the idea for the Pulsar UI framework was there would be a nicely compiled package that would be either hosted or distributed and that a Jadu product like CMS or Q would simply include this package, then add its own stuff on top. This turned out to be rather naive and fell apart as soon as we started thinking about theming Pulsar for the TPT Portal. If Pulsar was only distributed as a ‘built’ package, anything we’d have to do to theme the default styles would have to be overly specific to override the default selectors. Even something as simple as changing the font stack would have to be written as an override.
Now each product is responsible for compiling the Sass and has the opportunity to insert their own theme files into the build and override any base variables (all Pulsar vars now use !default) or to add completely custom Sass that doesn’t necessarily belong in Pulsar core, which is intended to be common across all Jadu products.
I plan on writing a bit more information about how Q extends Pulsar with its own custom components and how it all gets pulled in and built with the magic of Composer and Grunt, but that’s a post for another day. I also want to share more about what’s going on in Pulsar and the work we’re doing to improve the experience of our software for our users as well as improving how we communicate what’s changed for those of you already using Pulsar, so expect some nice changelogs coming your way soon.
So to catch up, some recent highlights (not just limited to 3.0.0) include:
- New html.panel component
- New html.label_group component
- Rewrote all helpers to remove the need for named arguments, now everyone gets along nicely
- Made all helpers compatible with Twig’s strict_variables mode
- Added an AttributesParser Twig extension to simplify how html element attributes are passed around inside macros
- Added new excludes() and only() array filters for Twig, now you can be a bit more bossy about what your arrays do
- Switched to the official twigphp/twig repository instead of jadu/twig which was a fork of fabpot/twig (did you follow all that?)
- Went through the 12 step programme and removed the Bourbon dependency from Sass
- Remixed the state colours (success, error etc) to meet WCAG 2.0 AA guidelines for contrast ratios, you can now read the text, which is nice
- Made buttons look pretty (buttons used to use Bourbon’s button styling, eww)
- Updated popover styling to make them a bit sharper and standouty (totally a word)
- Added Vagrant hawtness for running the Pulsar development environment in a VM like the cool kids
- Did a blog
Macro Madness
This is a biggy, and worth talking a little about. Since we first decided to use Twig as our templating language there was a known issue with using named arguments in inherited templates, I was able to ‘bodge’ a fix which, although it fixed our specific needs, didn’t address the underlying cause within Twig, the fix for this seems to have been pushed for the Twig 2.0 release so we couldn’t wait any longer, things had to change.
So over the past couple of weeks I’ve been rewriting all helper macros, which was a bit of a grind but absolutely necessary to remove that technical debt before we start plugging Pulsar into the CMS in the coming weeks. While I was in there I generally tidied, DRYed and polished things up, wrote a load of documentation and added the ability for almost every macro to support common options like Classes, IDs and data attributes which was only done on an as-required basis previously.
The macro syntax has changed too and arguments are now passed through a hash.
html.button({ ‘class’: ‘btn—-primary’, ‘label’: ‘Click Me!’})
Unfortunately this does mean some work will have to happen to update all views using the old macros, but to mitigate the impact of this, Pulsar’s macros (effectively, its API) will be versioned so that a product (like Q) can have some views running v1 while others are updated to use v2 and not have to lock their Pulsar dependency to ~2.* and miss out on any new features or bug fixes. Once the relevant teams sound the horn to say they’re no longer using v1 macros, they’ll be removed.
The new versions sit in a v2 directory, the actual path will depend on how you’re pulling Pulsar into your product, but for example:
Version 1
{% import ‘@pulsar/helpers/html.html.twig’ as html %}Version 2
{% import ‘@pulsar/v2/helpers/html.html.twig’ as html %}Think you have what it takes to work on a UI platform that will be used by a company full of engineers across many different products?
You should totally talk to us.
