It doesn't have to be complicated to build a custom Umbraco property editor

TL:DR: https://github.com/filipbech/dayofweek

I love the new backoffice, and as a frontend developer by heart, I’m very much a fan of build tools, TypeScript. All the things that make your project more scalable and fun to work with. BUT, sometimes (many times) you don’t need all of it. So here’s an example of converting an angularJS property editor. No NPM, no Vite, no TypeScript, no build pipeline! To see what I converted, here’s the <=13 version: https://github.com/Frost117/UmbracoDayOfWeek/tree/v13.0.3

JavaScript has improved a lot since the angularJS days of Umbraco. In this example I’m using exports, imports (with import maps), classes (with private fields), fetch for HTTP-calls, template-literals, and optional chaining - all stuff that we could only dream of back in those days…

A Simple Property Editor

A Property editor at the core is two files. An umbraco-package.json file that Umbraco reads to know what to do on the server and what JavaScript file to load in the client. And then that very JavaScript file (in this example called day-of-week.js).

You can read the documentation for umbraco-package.json to find out all the options, but a few comments on this one.

Line 23: It uses settings. Similar to the prevalues of old, and then using itself as the property-editor to set the default values (Line 29).
Line 16: It stores the data as a string (Umbraco.Plain.String) - Could have stored the value as a number - that might have been more correct :-D
Line 35: It uses inline localization. You can still choose to point to a file like before (it’s javascript instead of XML though), but if you only have a few labels, I like just putting them there directly

And then the javascript file with some comments

Line 5: it’s all a single class that we export and give a custom-element name (Line 48)
Line 5: the class extends from UmbLitElement that we imported above. We do this to get some convenient methods from both Umbraco (the localization-part in this example) and Lit (the templating etc).
Line 6: defining the properties in a static field, is how we tell Lit what properties should be reactive.
Line 26: this.localize.term() is available because of the UmbLitElement, and takes the translation key as a string-argument.
Line 32: calling this.requestUpdate() is how we tell Lit to re-render the view after we’ve changed it (a bit like when you’d call $scope.$apply() in angularJS days).
Line 37: dispatching the UmbPropertyValueChangeEventis how we inform Umbraco that there’s a new value to store.
Line 41: the render method is how we tell Lit what to show. In this example, we are really only parsing the displayList to a component from the Umbraco UI Library and listening for the change-event, which updates the local value and informs Umbraco.

That’s it! See this simplified code here: https://github.com/filipbech/dayofweek. Eric, Tony and the team behind the real package have taken it beyond that and added some authentication etc, so follow the original repo to see it in real life.

The Start of Something Beautiful

The beauty in this approach is the simplicity. By leveraging modern JavaScript features, and the new backoffice implementation, we can create powerful and reusable Property Editors without the need for complex build tools or frameworks.

I hope this inspires you to go play with the Umbraco backoffice. There is some new syntax to learn, but other than that, I’d argue it is just as easy to get a proof of concept up and running as it was in “the old days”.

If you have thoughts to share, I’d love to hear from you. Let’s keep building amazing things that expand the capabilities of the CMS ?

I’m on BlueSky (and most other socials) as filipbech - please reach out in public so everyone can learn from the discussions!

The above is the detailed content of It doesn't have to be complicated to build a custom Umbraco property editor. For more information, please follow other related articles on the PHP Chinese website!