There are upcoming changes to the way we generate
and verify setters so more test are needed to cover
all the corner cases that are being handled today.
Closes#2559
Replaces the multiple arrays of `DomView`
by a single array with `DomElement`s.
Note: this commit does not show a performance regression
(tested against the tree benchmark locally).
Largetable benchmark with `interpolationAttr` and 200 rows / 20 columns:
Time for destroy/create pair dropped from about 1260ms to about 150ms.
Related to #2298, but does not really fix it as we are still slow
if people are using `<content>`.
Closes#2297
The goal is to make implementing a renderer straight forward.
BREAKING_CHANGE:
- Renderer interface was redone / simplified.
- `DirectDomRenderer` was replaced by `DomRenderer`.
- `DirectDomRenderer.setImperativeComponentRootNodes` is replaced
by the following 2 steps:
1. `ViewManager.getComponentView(elementRef) -> ViewRef`
2. `DomRenderer.setComponentViewRootNodes(viewRef, rootNodes)`
- all `@View` annotations need to have a template, but the template
may be empty. Previously views that had a `renderer` property did
not have to have a `template`.
- `dynamicComponentLoader.loadIntoNewLocation` does no more allow
to pass an element, but requires a css selector.
Special syntax: `:document` can be used as prefix to search globally
on the document instead of in the provided parent view.
Part of #1675
Major changes:
- `compiler.compileRoot(el, type)`
-> `compiler.compileInHost(type) + viewHydrator.hydrateHostViewInPlace(el, view)`
- move all `hydrate`/`dehydrate` methods out of `View` and `ViewContainer` into
a standalone class `view_hydrator` as private methods and provide new public
methods dedicated to the individual use cases.
Note: This PR does not change the current functionality, only moves it
into different places.
See design discussion in #1351, in preparation for imperative views.
Pawel Kozlowski
Martin Probst
Tobias Bosch
Marc Laval