-
Notifications
You must be signed in to change notification settings - Fork 18
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
Why decide against a ready flexbox implementation #186
Comments
Hey, I think this is a good question, so let me explain in a little more detail. I was using yoga originally because I thought that I will be ok with flexbox-only and I wanted something production-ready. Or I mean something which is used in production (react-native is using yoga). stretch is a rewrite of yoga in rust, and it was created for the startup called visly. I had a branch using it instead of yoga but there were some api differences/difficulties (impossible to remove a child or insert it at some place or something like that) and that along with the fact that stretch was effectively unmaintained, made me to stay with yoga. stretch2 (now called sprawl) is fairly new thing, I will keep looking at it but for now I am staying with my own impl. And there are 2 another reasons why I want to stay with my own layout - I want it to operate on "external" tree (so I don't need to do any diffing) and I need BTW: there is also one another flexbox engine, called Taitank and there are some reimplementation in other languages: https://github.com/kjk/flex and https://github.com/jordwalke/flex To wrap it up, sure, flexbox is a lot of code but is also IMHO fairly straightforward thing to do. There are bigger problems and yoga/stretch/xxx wouldn't help me with those, they were actually staying in my way. |
Oh thank you very much, for the suggested alternatives and the response. The only reason I suggested stretch was because I read that the author has designed it with implementing css grid in mind, or so I thought. And I assume that css grid and flex are enough for 99% of any layout anybody might want to build. |
yeah, I mean the new fork looks promising so far, if it gets maintained again and if we somehow agree on the I hope to create a ticket in their repo this weekend, and expand my thinking, based on this conversation |
ticket here DioxusLabs/taffy#182 |
closing for now (limit scope before first release) |
I am pretty sure you have considered, building on top of:
A
stretch
fork eg: https://github.com/elbaro/stretch2, https://github.com/ivanceras/expanse but I am pretty curious why did you decide against it.If you find this issue irrelevant please close it without responding.
The text was updated successfully, but these errors were encountered: