feat: (Angular) support angular templates

[puschie286]

Creating new component from type is enough in most situations. When you have more complex requirements, your options are very limited - basically to either a derived component or a external configuration service, but it gets very complicated very fast - especially if you want to use angular input/outputs or content projection.

A much simpler angular approach is to use (ng-)templates. In these, you can configure/setup components or even component groups and use these as base for the component creation.

This PR adds supports for the angular templates.

Changes:

• Support template instantiation in angular renderer
• Support template refs in all views and component registry

Note: this is based on PR #1094
(it could be implemented without the centralized registry but depended on which PR gets merged first, the other would need adjustments).
I think stacked PR from forks are not supported yet, so github show all commits from the other PR here too

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 3df7dbc:

Sandbox	Source
dockview-app	Configuration
editor-gridview	Configuration
externaldnd-dockview	Configuration
fullwidthtab-dockview	Configuration
iframe-dockview	Configuration
keyboard-dockview	Configuration
nativeapp-dockview	Configuration
rendering-dockview	Configuration

[puschie286]

@mathuo i have not updated the 'Options' classes yet because i dont fully understand the purpose of them.

I would guess that the idea was to support 'UpdateOptions' like in the api but it was never implemented?

[mathuo]

@mathuo i have not updated the 'Options' classes yet because i dont fully understand the purpose of them.

I would guess that the idea was to support 'UpdateOptions' like in the api but it was never implemented?

Essentially packages/dockview contains all of the logic, everything. The framework packages should be pure wrappers with no differentiating "logic". You'll see PROPERTY_KEYS_DOCKVIEW used in all of the framework packages as a way to track what fields are "updatable" as options to dockview; when one of those options changes according to the specific framework we propagate that option into the core dockview library, if that makes any sense?

[puschie286]

Essentially packages/dockview contains all of the logic, everything. The framework packages should be pure wrappers with no differentiating "logic". You'll see PROPERTY_KEYS_DOCKVIEW used in all of the framework packages as a way to track what fields are "updatable" as options to dockview; when one of those options changes according to the specific framework we propagate that option into the core dockview library, if that makes any sense?

Sorry, my question was very unspecific. The part you have explained, is the part i still understand. But that stops at the angular specific view options like ‘SplitviewAngularOptions’ or ‘DockviewAngularOptions’. These exist for every view type but are not used anywhere

[mathuo]

SplitviewAngularOptions

Oh, they should exist the equivalent core library options to allow for angular specific key/values like rendering components. The react wrapper probably shows best how this is intended to work (for react in this case) where it exposes explicitly types Reacted components here

[puschie286]

So these are the component interfaces. Well its uncommon to use these for components in angular, especially because they cant have angular specific decorators (like @input) and are not compatible with the new signal flow either (where all inputs are defined as signal type).

We can use them, but they will not provide any advantages for angular users (and prevent adapting the signal flow in future)

[mathuo]

So these are the component interfaces. Well its uncommon to use these for components in angular, especially because they cant have angular specific decorators (like @input) and are not compatible with the new signal flow either (where all inputs are defined as signal type).

We can use them, but they will not provide any advantages for angular users (and prevent adapting the signal flow in future)

I wonder if there is any post-processing we can perform to maintain reading from the core libraries option list? the primary purpose of this is that when a new option field is added to the core library the frameworks shouldn't usually need any code changes. Some inspiration for how this works I took from ag-ggrid as they also support multiple frameworks with a core underlying library, their angular library seems to do some post-processing here and even mentions the input fields you notes.

[puschie286]

I wonder if there is any post-processing we can perform to maintain reading from the core libraries option list? the primary purpose of this is that when a new option field is added to the core library the frameworks shouldn't usually need any code changes. Some inspiration for how this works I took from ag-ggrid as they also support multiple frameworks with a core underlying library, their angular library seems to do some post-processing here and even mentions the input fields you notes.

ag-ggrid generates the angular component (i guess as part of the build process). In my opinion, this approach is extremely costly, because it add a lot of complexity and has high maintain cost - and that just to "save" a few simple changes now and then. At a time where frameworks move fast and have a lot of unique features/approaches, i think a direct implementation is much more reasonable for the size of this project.

We will use this project for at least a few years, so im fine with maintaining the angular part, if you need help with anything.

Personally, i see the framework packages as bridges to integrate framework specific approaches and adapt to their way of handling things (i mean this project will not change the way people use react/vue/angular^^)