Repository navigation
Build Compose HTML SSR EAP trees directly during composition - #5733
Clemens Koprolin (clemenskoprolin) merged 3 commits into
Conversation
| override val supportsDomElementAccess: Boolean = false | ||
|
|
||
| override fun <TElement : Element> elementBuilder(tagName: String): ElementBuilder<TElement> = | ||
| StringElementBuilder(tagName) |
There was a problem hiding this comment.
would caching / reusing the element builders help a bit?
There was a problem hiding this comment.
I tested it on the testing suit, it does not really show any clear performance or memory benefits.
| } | ||
|
|
||
| @Composable | ||
| @NonRestartableComposable |
There was a problem hiding this comment.
Can we have @ExplicitGroupsComposable for the composables here?
| StringHtmlElementNode(elementBuilder.tagName, namespace) | ||
| } | ||
|
|
||
| val attrs = AttrsScopeBuilder<TElement>() |
There was a problem hiding this comment.
I wonder if we can avoid re-allocating the AttrsScopeBuilder every time and save its reference in the node?
There was a problem hiding this comment.
Yes, this makes sense for keyed renders. I added it there.
| val previousIndex = index | ||
| parent = node | ||
| index = 0 | ||
| content?.invoke(StringElementScope()) |
There was a problem hiding this comment.
Let's create a constant StringElementScope() and pass it to all invoke?
Move shared serialization helpers into their own file. Co-authored-by: Oleksandr Karpovich <a.n.karpovich@gmail.com>
| private val hydratable: Boolean, | ||
| private val attrsBuilders: AttrsBuilderPool? = null, | ||
| ) : ComposeHtmlContext { | ||
| private val output = StringBuilder() |
There was a problem hiding this comment.
Is it worth it to try to reuse a StringBuilder too by adding it to ReusableHtmlComposition?
There was a problem hiding this comment.
Yes, that helped. It reduced the subsequent render times by ~10%!
There was a problem hiding this comment.
Nice! Let's merge this PR :)
This PR improves Compose HTML EAP string rendering by building HTML
trees directly during composition, avoiding recorded HTML node factories
and updates. The existing
composeHtmlToStringandrenderHydratedDocumentAPIs use the new implementation.
Serialization avoids copying validated attributes and appends ordinary text in bulk.
In our testing, warm rendering takes about 48% less time than master
across eight shared workloads. All eleven measured warm workloads improve.
Involves CMP-10836
Testing
Run from the
htmldirectory:Release Notes
N/A