Any ideas for Label Templates? (AngularJS expression replacement)

[leekelleher]

Starting off with an initial question... do we have any ideas what the replacement for AngularJS expressions used within the backoffice? e.g. Block List label templates, a la "{{ propertyName | ncNodeName }}"

Should we be looking for a library to support the existing structure? e.g. Mustache-esque syntax with piped filter functions.

or could we consider a more generalized template syntax for use across different components of the backoffice? (for things we haven't considered yet.)

Any thoughts, ideas, brainstorming?

[leekelleher]

I didn't want to pollute the initial question with my own suggestions.

For Contentment, I need to figure out a way to do the Data List's Templated List UI editor, where currently an AngularJS template (markup) can be entered (in the backoffice) and used to render list items.

From my current exploration of existing Lit-compatible libraries, I found one called Stampino - it looks very promising. Under the hood it uses a library (by the same developer) called jexpr, which could be used to handle label templates for Block List, et al.

[madsrasmussen]

I am just throwing some very early-stage ideas into the pile here. I would like the templating language to be extendable by packages, and easily reusable by others.

It would be cool if a package could add a new function through the extension registry. With all functions in the registry, we could build some good DX/UX on top of it with a suggestion dropdown, inline documentation, etc.

With a bit of inspiration from Sheets, Excel, and Mustache a template could look something like this:

{{ MY_FUNCTION(arg1, arg2) }}

Manifest:

{
  "type": "templateFunction",
  //...moreManifestProps
}

[iOvergaard]

A Mustache function template looks like this:

{{#bold}}Hi {{name}}.{{/bold}}

Which is a nice way to fill out a "default slot", I think.

The function declaration itself looks like this:

{
  "name": "World",
  "bold": function () {
    return function (text, render) {
      return "<b>" + render(text) + "</b>";
    }
  }
}

Would it benefit us to use Mustache.js outright?

[madsrasmussen]

It might also be possible to extend the markdown parser with custom "syntax". Then we could go the markdown route as Filip mentions in the comment below. 🤔

I would still prefer to have an option to register functions in our registry compared to a "fallback" to custom elements. It gives the advantage of looking them up for additional functionality. It should be possible to make the context API available in our functions/classes as we do with all our API extensions.

[filipbech]

could it be just markdown? That makes all the simple things out of the box, and it falls back to html, which would allow you to use your own webcomponent if you need more advanced stuff...
It would give you the things you already know, like context through providers etc...

When I talked this over with Niels a little way back, I think we identified the biggest problem would be how to use that for attributes or something that needs to be a string and cant be an element... i dont know what the solution to that is

[iOvergaard]

I think some of the label and description fields in the old Backoffice support Markdown already. If that is the case, then we probably need to support it in Bellissima as well -- maybe just as a fallback.

[skttl]

The description fields support a subset of markdown, not a complete implementation IIRC. I did the PR back in the days :)

[JasonElkin]

Markdown seems overkill for labels - do people really want to shove all kinds of HTML in there?

It doesn't solve the expression question, which I think is the more relevant part of @leekelleher's point than the actual markup (if indeed there needs to be any markup for the average label).

[glombek]

I've used markdown in a description once or twice, for emphasis.

But I think the markdown discussion may be a confusing property labels with label templates (as used in block lists and the grid)

[iOvergaard]

Regardless of what we choose to ship by default in the Backoffice, an idea I would like to put forward is to let packages register a template rendering engine of their own meaning, that if an Umbraco developer would like to use another parsing library, they could register it themselves. The registration would have to declare some kind of start character sequence, i.e. {{ like Mustache, or # for the localization lookup engine, that we already provide. In a way we have moved down this path already, you could say, since we have # for localization and talking about another character for dictionary lookup.

Example registration:

{
  "type": "labelRenderer",
  "js": "./my-mustache-js-integration.js",
  "startSequence": "{{",
  "endSequence": "}}"
}

[Bakersbakebread]

My common use case for angular expressions is transforming data/properties into something more human readable.

Is there a world in which the backoffice can support a selection, instead? There's arguments for all of the above but not always all of the above. Sometimes I just want to format something, sometimes I need to extrapolate something and sometimes I need to do something a little bit fancier (math or what not).

A somewhat rough example of what I mean.

My biggest gripe with the current angular JS templating is, albeit fairly straightforward, it really is not and often requires a bunch of googling / asking for help if not just to refresh me on how it all behaves.

I'd vote that consistency would be king here.

ps, having a preview would be super beneficial too. Having to save and then tweak is draining. :)

[markadrake]

We turn to https://squirrelly.js.org/ for templating most of the time.

I would like to second the suggestion to make this something we can swap out if another engine better suits our needs.

(Of course something could just be built using Lit.)

The one thing above that I would push back on is the extra clicks—I think this is better suited for your Umbraco manifest (making the selection of templating engine).

[deanleigh]

The two places I use Mustache-like syntax is labels as discussed and values in our fallback package.
I still believe it is critical that we can display fallback values in inputs and labels come to that matter.
This example is for using the page title as the og title:

This example is using the following mustache to show is a feature is published among other things:
{{$settings.wFtSetPropPublished == '0' ? '🚫 ' : "🟢 "}}{{$contentTypeName}}{{wFtPropTitle ? ' - ' + wFtPropTitle : ''}}

I very much like working with this syntax

[JasonElkin]

The key difference between the above, which are AngularJS Expressions and mustache is that mustache is logic-less i.e. no ternary operators etc.

[glombek]

Although it looks like common extensions exist for this. But veering away from the standard is not ideal. It also seems quite verbose!

[madsrasmussen]

I can see that we already have the "Marked" library (mark-down parser) as a dependency. Maybe we should see how far this can get us in the first run?

https://marked.js.org/

[glombek]

I'm not sure that Markdown handles variable-substitution, that Umbraco has previously used Angular for.

[leekelleher]

@glombek I had the same thought about the use of AngularJS expressions, that was until @madsrasmussen pointed me at the Marked library's extensibility docs, https://marked.js.org/using_pro, then I could see how this approach could be used as a more generalised approach for label templating across the backoffice.

There are examples of 3rd party Marked extensions: https://marked.js.org/using_advanced#extensions, and one that caught my eye was Govspeak (a GOV UK flavoured markdown), to give ideas of extensibility.

I'd envisage the Umbraco would have a bunch of built-in extensions for common use-cases, e.g. ncNodeName, or general JS expressions within Mustache-esque syntax.

[greystate]

I use Label Templates a lot in BlockLists, Listviews and BlockGrids as well as in Contentment — if I could make a wish here, it'd be for there to be easily-accessible documentation for these, right where we use them, e.g. like the way you can get a list of the supported placeholders for an XPath in the MultiNode Tree Picker. Right where you need it. I'm sure we all have our little Post-Its with “Get name of media item in BlockGrid inside a BlockList” etc... this info would be very nice to have in one single place, but more importantly it would be nice to have access to the most important bits, right where we need it.

[ravimotha]

What grey state said .. auto numbering and name generation from the block list item typically using things form this marvellous list
https://joe.gl/ombek/blog/umbraco-angularjs-filter-cheat-sheet/

The only other editions would be help on things like images (image names/alt)

[glombek]

I like Mustache as a (default) option. Mustache is well-used enough to be trustworthy - I'd be wary of any more niche libraries. I like the idea of being able to register custom Mustache functions. I also like the idea of being able to register different string parsers as suggested by @iOvergaard

Another option would be to stay even more native and use the JS template literals syntax.
e.g. Tab panel (${ tabs.contentData.length } tabs) with some custom functions and variables injected into scope too: ${ $contentTypeName } - ${ umbWordLimit(bodyText, 5) }

However, this would require the use of the dreaded eval function to parse the contents as a literal, and would require some level of sanitization. But I thought I'd suggest it as a "vanilla" JS solution.