Skip to content
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

Closed
alex4o opened this issue Jun 12, 2022 · 5 comments
Closed

Why decide against a ready flexbox implementation #186

alex4o opened this issue Jun 12, 2022 · 5 comments

Comments

@alex4o
Copy link

alex4o commented Jun 12, 2022

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.

@cztomsik
Copy link
Owner

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 Block display mode which unfortunately is not 100% possible to emulate with flexbox.

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.

@alex4o
Copy link
Author

alex4o commented Jun 15, 2022

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.

@cztomsik
Copy link
Owner

cztomsik commented Jun 18, 2022

yeah, I mean the new fork looks promising so far, if it gets maintained again and if we somehow agree on the Tree trait so I don't need to do any diffing/syncing then I might switch again, I didn't put too much energy into layout yet.

I hope to create a ticket in their repo this weekend, and expand my thinking, based on this conversation

@cztomsik
Copy link
Owner

ticket here DioxusLabs/taffy#182

@cztomsik
Copy link
Owner

closing for now (limit scope before first release)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants