In Umbraco 13 (AngularJS-based backoffice), building a custom property editor inside a Block List was relatively straightforward.
With a small amount of Angular scope traversal and a single API (contentTypeResource), it was possible to:
- identify the current block
- retrieve its content type
- list its properties
- map aliases to labels
This could be achieved in a few dozen lines of code and was easy to reason about.
In Umbraco 17, using the new Backoffice stack (Web Components, Context API, Repositories, Vue/React, Vite/Node), the same task becomes significantly more complex, especially in nested scenarios.
Where complexity is understandable
Some parts of the new architecture clearly justify additional structure:
- Strong separation between content, settings, workspace, and entity detail
- Context-based communication instead of implicit scope traversal
- Repository-based data access instead of ad-hoc HTTP calls
- Framework-agnostic Web Components instead of AngularJS coupling
These changes make sense from an architectural and long-term maintenance perspective.
Where complexity becomes problematic
The difficulty arises specifically in deeply nested scenarios, such as:
- a custom property editor
- inside a Block List
- opened in a modal block editor
- where both content and settings element types exist
In this situation, performing what should be a simple operation (e.g. “get the current block’s content type and its field labels”) requires:
- understanding multiple contexts (Document Workspace, Block Workspace, Block Entry Context)
- distinguishing between contentElementTypeKey and settingsElementTypeKey
- dealing with state/observable wrappers instead of plain values
- resolving mismatched identifiers (contentKey vs key vs udi vs route parameter)
- sometimes manually matching layout, expose, and contentData arrays
- in some cases falling back to parsing the modal route to reliably identify the active block
From a developer perspective, this feels fragile and unintuitive, especially when the data is clearly already present in the Block List value.
Practical consequence
Simple editors (for example: a dropdown that shows field labels but saves field aliases) now require:
- deep knowledge of Backoffice internals
- extensive logging and debugging
- defensive fallbacks for contexts that resolve differently depending on whether you are editing content or settings
- significantly more code than the equivalent AngularJS solution
This increases development time and makes it harder for teams to confidently build and maintain custom packages.
Expectation as a package developer
What would greatly improve the developer experience in these cases:
- Clear, official guidance specifically for “nested editors inside Block List modal”
- A documented, reliable way to identify “the block currently being edited”
- A simple API or context method that resolves the correct content type for the active block (content, not settings)
- More examples that go beyond basic editors and cover real-world nested use cases
The new Backoffice architecture is powerful and well-structured, but for nested scenarios like Block List property editors, the cognitive and implementation overhead currently feels too high compared to the problem being solved.
If anyone has concrete tips, patterns, or recommended approaches for handling nested scenarios like this (custom property editors inside Block List modals), they would be extremely valuable.