Custom Block Grid Views: Too Complicated

[thenexus00 (Liam Dilley)]

You are right but It would be good for Umbraco to not go do what say Kentico has done.

Kentico with its “13” which they hardly done anything with is .NET core(new .NET) MVC but odd. Front end that but back end still portal.

They used to have a lot of easier to create things, web part concepts and so on but that is all gone and while they offer API features for most aspects of the system nearly everything now has to be “Build it yourself”. And they just put some sample code on the docs.

It is OK but considering the cost of it, its pretty dumb.

Umbraco is free but again, one of the big draws was the barrier to entry, the learning and the expansion. The barrier to entry will of course sometimes move up but I think it is loosing sight of some its attraction.

Remember in Umrbaco 7 and improved through 8 you could build your content pages and grid and various content items and you could see most of it rendered in output. Later you could get some examples of the core ones.

• You have pure Javascript and web components to create them - Great
• You can go further with the more Typesript etc output - Great
• If someone wants to just make a simple content card block and just at least have the basic content cards and info show for the end user in the grid so they have better context of what they are seeing - To much work right now.

And then as noted, the magic string are gone and the Umbraco team trying to build their own but it does not have any of the logic the previous implementation had and that will take work.

If you had that layer of say JS Liquid that worked in fields/Labels for basic string conditions to display names, default names and an easy way to tap into the models of your element / document types to be able to quickly create some back end output in your grid then you can focus on other things.

You can do some great stuff for your custom plugins etc and do complex things but I think you just need that quicker, lower effort option create your back end visuals for your custom components, labels etc. That liquid use can filter to the Umbraco forms as well for example.

It is not to do with being lazy or anything. But working on large web projects got far better things to do than have team sync time in making even basic output renders, especially when there is little to no documentation and hard to debug right now.

[thenexus00 (Liam Dilley)]

A UI is also nice but takes time, space etc. It is why I have always liked Liquid for various use cases because it is very easy to follow and defiantly easier to follow than:

{{$settings.featureSettingsPropertyHideDisplay == ‘0’ ? ' ’ : " "}}{{ $index }} - {{$contentTypeName}}{{featurePropertyFeatureTitle? ’ - ’ + featurePropertyFeatureTitle : ‘’}}

LOL

[thenexus00 (Liam Dilley)]

UMB needs to be built out to match anything like in Angular magic strings. It is a key feature in Umbraco forms to do various funtionality.

Most people need a name displayed for a list of items and point to the property that holds that name etc as the most common use case and some conditional logic with fall back value. Sometimes you need a bit more.

The JS Liquid gives you more, a lot of it is done, easy reference to documentation, liquid is easy to follow (Compared to UFM and Angular magic strings)

Having it in the label there is not exposed to the main user of a site and is done by a developer.
It is indeed small box as you noted.

I do not like what Kentico did with their K# templating but it did have this:

For Visiablity it was true or false but if you wanted to show the thing in question only if a URL paraemter existed you had macro;s (The #) and logic you could apply. A lot of that is redundant with the MVC and doing things properly in views.

@deanleigh mentioned a UI so you could have the option to click, get and be it UFM or Lf you replaced that with the JS Liquid markup you could build the logic, have some help tools in the modal to build it and ultimately it would the same output but get you what you want.

• It can be empty
• Can be basic text
• Have the logic “magic string” support and a lot of the time people just do really basic ones
• You can click to expand and add a little more logic.

Again the intention and where I am getting at is that for me having a good experience for the end user in the Back office has been important and why many have loved Umbraco and I love building because I can give them a good experience and a lot of it has been very easy and a natural part of the platform.
This allows us all to focus on the functionality of the projects, the front end, the integrations with 3rd parties, payment systems and so on.

I just really do not want to keep investing more and more time writing more and more code and files to make the back office useable.
You CAN - GREAT, but one of the key attractions to me with Umbraco and the Grid concept was I did not have to invest much time to get a nice output.

[jacob (Jacob Overgaard 🚀)]

@thenexus00

I just really do not want to keep investing more and more time writing more and more code and files to make the back office useable.

The way I see the new Backoffice is that we now have a solid foundation for people to build extensions to enrich the editor functionality.

You can extend many places already, and if we need more, we can easily add it without causing trouble to existing extensions -

One thing we could do next or in the near future is abstractions -

As you say, currently there is too much boilerplate code to get what you want – although I did provide a very slim two-file solution back in my earlier reply: Custom Block Grid Views: Too Complicated - #3 by jacob

I am certain we can figure out ways to abstract manifest registrations away. One obvious way could be to investigate JavaScript decorators. That has the potential to bring my solution down to one file:

import { html, css, when, customElement } from '@umbraco-cms/backoffice/external/lit';
import { UmbLitElement } from '@umbraco-cms/backoffice/lit-element';
import { umbExtension } from '@umbraco-cms/backoffice/extension-registry';

@umbExtension({
      type: "blockEditorCustomView",
      alias: "my.block",
      name: "My Block",
      forContentTypeAlias: "imageBlock",
      customElementName: 'my-custom-block-view' // <-- Potentially leave out for auto-generated name
})
@customElement('my-custom-block-view') // <-- Perhaps not needed if set by umbRegister
export default class BlockCustomView extends UmbLitElement {

    static properties = {
        content: { type: Object },
        settings: { type: Object },
    }

    render() {
        return html`
            <p><strong>Text:</strong> ${this.content?.text ?? 'No text'}</p>
            ${when(this.content?.image?.[0]?.mediaKey,
                    (unique) => html`<umb-imaging-thumbnail class="thumbnail" width="300" height="300" mode="crop" unique=${unique}></umb-imaging-thumbnail>`,
                    () => html`<p>No image</p>`
            )}
        `;
    }

    static styles = [
        css`
            :host {
                display: block;
            }
            
            .thumbnail {
                max-width: 300px;
                max-height: 300px;
            }
        `,
    ];
}

And so, we can continuously build logical abstractions on top of Umbraco’s powerful Extension API to help developers.

That being said, I do agree we need something like LiquidJS to render out magic strings (or label templates, as we call them). It is currently an ongoing project to figure it out.

Bonus: The Backoffice already exports a JSON schema for extensions. Using this file, it would even be possible to generate a C# SDK around extensions to register them in the backend (see here for a type-less example).

[thenexus00 (Liam Dilley)]

I think it is OK and you can do a lot and that is a good thing but as we discussing the barrier of entry and effort has shot up.
I remember when we moved to 8 and the slow pickup of packages there. It finally got going again then 9 happened. Then we got some flowing again and now from 13 to 16 there is a massive drop in packages again and this time there is a VERY SLOW conversion rate.

15 in general with the backoffice was pretty buggy and clunky, I am still surprised that released. 16 is OK but there is still heaps of things simply not working any more directly and I see lots of github repo’s like the popular conditional properties one with people asking for 15+ versions and all the authors have said the same thing s. They are all having issues converting them or getting them to work.

It is a quite but big issue right now.
I think as we are discussing it is a multistep process:

1. Better documentation:
In general it needs a lot of work. I tried to make a Umbraco forms workflow in 16 yesterday and it took me ages to find the correct field definitions now. For the custom views some better examples, some clear documentation.

2. UFM Replaced: (Umbraco Flavored Markdown | Umbraco CMS)
Was great to see that Umbraco trying to offer a replacement for the Angular magic stings but it is basic and would need a lot of work for the conditional logic. Replacing this with Liquid be it Liquid JS or Liquid .NET would mean better logic to be able to use in the labels etc. The primary use cases are things like if you have a title for a block but if empty render default etc.

3. Lower level entry for the backend views:
I think what is implemented is totally fine and people seem to agree with good options and good stuff to build custom solutions. BUT the barrier of entry, what Umbraco is and what was on offer before has been lost.
Either with support for a Liquid JS based view or other solution to allow quicker basic output for a view.
Most of the time you just have a web page with a grid and custom grid output and custom blocks you just want to have some output for the user and not spend a lot of time making them to focus on the actual development of the site.

4. Some default presets offer.
What there was with the image and rich text editor as some basic starting points on offer helped. IF there was a similar addition in 16+ to then create these JS files you can then look at, copy, update and learn from would be helpful

5. Option: Future Abstractions
What Jacob has said is valid suggestion. Having that where you could have a basic rendering solution you just feed it your properties and any extras to render an easier output.

If by default if you just used an import, create your view and simply wanted “do default”. It would just loop through the properties and render the resulting content.