You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of mounting and unmounting the elements ourselves, I suppose it would make sense to use portals in yew to put them there.
A plan to address this is to slightly change the StyleManager api introducing a trait StyleHost that implements the behaviour of the manager, along the lines of
The current impl of mounting elements by hand can be retained by putting it on the Builder or some other class, but the stylist::yew::ManagerProvider components would use an impl that renders the mounted elements (with a portal) to the place where they should be mounted at, e.g. something along the lines of
<ManagerProvider><StyleHosttarget={target.or_else(document.head)}> // StyleHost creates the portal for its children
{formounted_styles}</StyleHost><ContextProvider<StyleManager> ...>{forprops.children}</ContextProvider<StyleManager>></ManagerProvider>
It might also make sense to have an InlineStyleHost that renders the style elements simple at the point in the DOM where it is mounted.
The text was updated successfully, but these errors were encountered:
RenderRunner::<ManagerProvider>::run (style is rendered)
It may also degrade performance when the number of style tags is large as virtual dom now needs to diff every <style /> tag and its content every time a new style is added (VDiff::apply) where as current method just needs to append a style tag.
In addition, it seems like this also makes <ManagerProvider /> mandatory?
I personally do not see a big advantage of using portals, but if you still want to give it a go, feel free to do so, and I will see how it goes in the PR.
I've finally come around to benchmarking this, and it confirms what you've been worried about. The yew diff algorithm is a big hit to performance, hence I don't think it's worth going down this road further.
One thing that might be worth thinking about would be to have a StyleHost trait as mentioned in the first comment - but this could be done by popular demand and in a different issue.
Instead of mounting and unmounting the elements ourselves, I suppose it would make sense to use portals in yew to put them there.
A plan to address this is to slightly change the
StyleManager
api introducing a traitStyleHost
that implements the behaviour of the manager, along the lines ofThe current impl of mounting elements by hand can be retained by putting it on the Builder or some other class, but the
stylist::yew::ManagerProvider
components would use an impl that renders the mounted elements (with a portal) to the place where they should be mounted at, e.g. something along the lines ofIt might also make sense to have an
InlineStyleHost
that renders the style elements simple at the point in the DOM where it is mounted.The text was updated successfully, but these errors were encountered: