Anyone played around with trying to access BlockGrid / BlockList labels via a backend controller? (Or via Typescript for that matter). Working on a new little block picker package for doing things like anchorlink style menus. Currently using the data type service to grab the UFM syntax, but not entirely sure if I can resolve it server side or if Ill need to throw the content key to the client side to resolve the label there. (Screenshots just a little preview of what I've got so far. Rendering nodes then whatever Block grid or Block list it can find on the page then finally selectable blocks within those) https://cdn.discordapp.com/attachments/882984798719729704/1501906629988188342/image.png?ex=69fdc70c&is=69fc758c&hm=bf6fa056f7ef1acfee2a727d8a8fd7f34f271e5a4c54f6287fe8c9f5870c22c7&

Not sure if this helps but for our jump-list / in-page anchor menu we went a different route and might be useful as a comparison. We don't auto-resolve labels at all; the editor adds a multi-content picker on the in-page-nav block, and the labels come from each picked block's own featurePropertyFeatureTitle property at render time (Razor reads block.Content.Value("...") for each picked content key). Slugs we generate from the title server-side. No UFM, no client-side resolution. The picker just stores content keys; labels resolve naturally as part of normal block rendering. Means we don't have to know about block types in advance — anything with a title property surfaces correctly. Happy to share the Razor view if it'd help.

Hey @Dean Leigh appreciate the insight! Yeah I had thought of the route of instructing people to add a property to their blocks, but thought against it as I wanted the package to be generic enough that a dev wouldnt have to add an additional property to the blocks to render the picker labels in an easy to see way. I might look at including some sort of override as I do think the ability for people to do that could be useful. I think I might have found a route forward using the umb-ufm-render tag by passing it the labelTemplate + content value from the API controller that powers the web component. No idea if its the "correct" way to go about it, but it seems to work and resolve! (https://github.com/WebwondersNL/Webwonders.Umbraco.BlockPicker/blob/main/src/Client/src/block-picker/block-picker-editor.element.ts#L117)

Hey @Tom Chance we're not actually requiring a property either. The picker stores content keys, and at render time we just call block.Content.Value("featurePropertyFeatureTitle") for each one, but that's only because our blocks happen to have a Title property. We could just as easily fall back to block.Content.ContentType.Alias or the element type's name, or even the label templates via UFM if a title isn't set. Editor adds an instance, picker shows whatever you choose to surface — title, alias, label template, anything. So we get the "easy to see" label without forcing the dev to add anything. I'm using contentment for the block picker just so I can make a nice interface Shows icons from the back office as well It uses the same icons that you pick in the back office. However, your umb-ufm-render route sounds cool as well, using the editor-defined label template means you inherit whatever's been set up in the data type, which is probably the most "correct" answer for a generic package. https://cdn.discordapp.com/attachments/1501906630332125324/1501939728268923091/image.png?ex=69fde5df&is=69fc945f&hm=86c25cc1f8489e0ffdc5918ab8ed389c902008fb339983a224e8b0562b1fb7e9&

Aha I see, I had misunderstood. Yeah certainly makes sense! I think I need to look at a way of allowing a dev to override the label option via appsettings so if they'd like to target a particular property on their blocks to act as the label they can. Would make for a clean solution!

I must admit I am finding UFM A bit tricky but I know it will improve We went to a lot of trouble to create a couple of fall back packages for text and images in the older version https://our.umbraco.com/packages/website-utilities/wholething-fallback-text-property/

Yeah felt like a big downgrade in knowledge after we all got used to angular moustaches! haha

It would be great if there was a native block picker I thought it could be integrated into multi node tree picker but I think that could Get complicated pretty quick and the multi node tree picker is already fairly complex for editors

We had the exact same thought here! The UX of the picker would definitely need careful consideration because indeed, having another choice slapped at the top would probably tip some editors over the edge with the burden of choice. I do wonder however with the new backoffice and some of the new extension types whether it might be possible to extend it ourselves. However, probably asking for data misalignment issues if we try going that route