Configuration Predicate Presets (or just Predicate Presets) is a new feature to Unicorn designed to help you get rid of a lot of configuration repetition on your projects.
If you’re following Helix guidelines for Unicorn (not saying you should but many of you are), there’s a good chance you have a flock of configuration files in your projects looking something like this:
And so on. Your <include>s might look a bit different but you get the idea.
With a Predicate Preset defined, you could remove some of the obvious redundancy here. Following this example you could add the following to the Foundation.Serialization.Base configuration.
Now that’s more like it. This is more in line with how I recommend using and implementing Unicorn. Minimise the project clutter, don’t mix serialisation configurations all over the place, and don’t mix your Unicorn serialised content with Visual Studio project assets. I know right?, gasp and so on. You are free to choose your own path obviously :-)
A closer look
So Predicate Presets works as an extended Configuration Parser. What that means is, that the preset handling happens when a configuration loads.
And from that point on, everything is as it has always been.
The important take away from this is, that you must include some sort of variant in the name attribute inside your Predicate Preset. If you don’t, Unicorn is going to get angry with you.
As for the tokens, it’s actually as simple as it looks. The Predicate Preset Parser will - generally speaking - take attributes from the preset definition and use them as tokens when expanding the Predicate Preset. This is probably best explained with a few examples.
From this, the Predicate Preset Parser will first try and resolve $database from <preset id="Component" name="Carousel"> but there is no database attribute to be found. It will then look to the Preset Predicate Definition <preset id="Component" database="master"> and find database="master". So $database becomes master and this is then replaced using simple string substitution on all attribute values in the preset.
The process is then repeated for other tokens, in this case $name. The important take away here is, you are completely free to come up with as many attributes as you want or need.
The system is very flexible and I’m sure you can think of better uses of it than I can, I’m mostly focused on explaining all of this and writing this post ;-) I could easily see this being used in for instance SXA, with tokens like $tenant and $site.
In summary
Predicate Presets can help you avoid configuration duplication and keep consistency in your solution. It makes for much easier configuration setup and maintenance and provides you with a much better overview of what you have going on in your solution. Especially so, if you take my recommendation and turn the dial way back on the number of configuration files you have in your solution.
If you find Predicate Presets useful and you put them to good use in your projects, don’t be shy. Reach out to me and share what you’re doing. I would love for Unicorn to ship with some of the best and most widely used Predicate Presets out of the box. Especially if you come up with ones of general use for JSS and SXA projects for instance.