-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LayoutPartialTree low level api is restrictive #710
Comments
Did you look at the current master branch code? It might already fix your issue. https://github.com/DioxusLabs/taffy/blob/main/src/tree/traits.rs#L169
|
It's funny that you have this issue now, as I have just been dealing with the exact same issue with the html5ever crate. This definitely seems like a use case we ought to cater for. I think the new trait-based API for Style on the master branch ought to sort your problem with the style method(s) (it's now multiple methods). You'll need to implement For the get/set layout methods I think we can make them work by value if need be. I think you might be right that we might need another trait for the Cache. It's really not ideal that everything needs to be so generic, but I guess it's better to make things possible than not. We could also potentially just add We may also be able to use the |
Alright! wow yeah great timing. looking through the new wrt to the set layout methods - they seem to be fine as references, references can always be cloned when they're incoming, its just returning references which can be problematic. Well stuff is looking good I'm going to give an implementation based on the master branch and see how that works out, or if there are additional issues unresolved by the new interface. |
What problem does this solve or what need does it fill?
It would be nice if there was a less restrictive low-level api, within my UIs node structure my nodes are not owned but are subject to interior mutability (my trees own something akin to Rc<RefCell<Vec>>), hence unless I'm missing something (which I very well may be) its impossible for me to return the references (
&Style
,&mut Cache
) as required byLayoutPartialTree
as it breaks rust ownership guarantees. For reference here is the current trait:What solution would you like?
I'm not 100% sure on what the ideal solution really would be. In my exact scenario a API which returned an owned
Style
(this would be a performance cost) andRc<RefCell<Cache>>
would work, however returning theRc<RefCell<Cache>>
really doesn't seem ideal to me either as this doesn't leave room for alternative mutability patterns.MAYBE creating a Cache Trait would actually be the more versatile solution. Something like:
Ideally it would be cool to have a solution which doesn't introduce any significant performance cost (
&Style
->Style
might, I'm not sure); and also isn't just a second low level api for maintainability purposes. Curious if anyone else has other thoughts, maybe folks like I just need to use my workaround (below), however I bet there is a good solutionWhat alternative(s) have you considered?
Right now, I figured I can just use the high-level api as a workaround and rebuild the tree for each time a recomputation is required. It's just not the nicest solution but it will work.
The text was updated successfully, but these errors were encountered: