[Feature] Support CSS Grid #867
Assignees
DaddyFrosty
Clear assignees
DaddyFrosty
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: DaddyFrosty/yoga#867
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Report
It's been advised to open a new issue (from this closed issue from 2015). Related react-native issue
It's been 4 years since the issue was closed. This issue is to request evaluating if supporting
display: gridis worth reconsidering now.It is the
11th8th top request(1st in regards to layout,8th3rd trending) at229(Mar 2019)359(Feb 2020) votes on React-Native feature requests, the feature request was created in December 2017 with steady response of support from users since then.I'd like to voice my support.
Great! Just give it a positive reaction like many others have done :)
(That goes for anyone else that has an itch to make a +1 comment)
Is anyone aware of other efforts to make a cross-platform implementation of CSS Grid? I would love to support this. It's worth remembering that CSS Grid has a larger API surface area than Flexbox, so adding it here would be quite an undertaking and a big change to Yoga. Maybe a way forward would be a separate project which could serve as a reference or proof of concept.
@bnjm The css grid polyfill is completely web-independent, and supports most grid features already.
https://github.com/facebook/yoga/issues/47
+1 to get CSS Grid as part of Yoga (and potentially part of React-Native)
I would like that
Any update on this?
It would be nice to have Grids as part of Yoga otherwise it seems very incomplete.
Please, this would be huge. Since most browsers support this in some way, we're starting to use CSS grid as a standard in our React dev. Would be great to be in sync with RN dev.
@RodRitter same problem for me.
Some of you might be interested to know about a year ago an alternative was announced called Stretch:
And 9 months ago, HackerNews thread, author replies:
Website: https://vislyhq.github.io/stretch/
While it's probably of no use to the majority here that probably want CSS Grid to land in yoga for usage in React-Native, anyone that would be open towards
stretchas an alternative, I've raised a related tracking issue for CSS Grid support over on the stretch repo.Almost a year in since creating this issue, it would be fantastic to hear back from a dev of this project, if there is any hope for seeing Grid support arrive in future.
Agreed!
It’s much harder to share components between web and native if we can’t use grid for component layout in one, when it’s such a lovely feature of making components on the web now.
Sent from my iPhone
Any news on this? 🙏🏼
The mentioned stretch project recently started discussing how to start implementing Grid support.
Doesn't seem like there's any interest from devs on yoga. Perhaps at a later date it may be possible to substitute yoga for stretch?
Just subscribe to the issue if you haven't already and you'll be informed of any news. No need to notify everyone with a new message asking, we see the same issue thread content as you 👀
Let's try avoid requests for updates, cheers 👍
I'm fairly used to use CSS Grid instead of Flexbox in web development. Lack of support for CSS Grid is a deal-breaker to me.
i hope stretch substitute for yoga.
Would be a great addition
Update in 2020? Ooops it's almost 2021
Update in 2021 ？ 2022 will be come
Commenting here for the sole purpose of asking for updates or expressing interest doesn't serve any purpose or provide any value than all those that have done the same before you.
Please refrain from this behaviour.
It just annoys all those who are subscribed for notifications and actually hoping to see an update with positive news.
Before adding a comment and notifying everyone here, please consider the following:
Stretch) seems to have become stagnant with no activity on the grid feature. If that changes and sharing an update here would be beneficial to notify all subscribers, let us know 👍Someone has to want the feature enough to devote the time into making it happen and that likely won't happen without decent financial backing / incentive.
The best we can do is show demand for it as users (as described above)..... and be patient. Alternatively setup a bounty and pool funds into that.
@TheEhsanSarshar I would not say there's no traction on this, we have 600+ emoji on the top post.
What's the "emoji threshold" to consider the issue not-worthy from the users point of view?
For any team who built its web-application on css-grid feature, having react-native not supporting it is a deal breaker (and btw I seriously don't see any reason to create layouts with flex in 2021, beyond supporting IE11).
But if the yoga team is not considering this feature, a clean statement like "we are not working on this in the foreseeable future" would be much appreciated when closing this issue! 🙃
A bit of an update for everyone on this issue:
Stretch was forked as Taffy in May 2022 under the auspices of the bevy and dioxus projects, and is now seeing regular maintenance, as well as new feature development work.
It should be noted that unlike Stretch, Taffy does not currently have bindings to languages other than Rust. However, we are open to adding them, and would welcome contributors interested in developing and maintaining such bindings (and we'd be able to provide mentorship on the Rust side of things).
Also relevant to this issue: we have an in-progress implementation of CSS Grid! The CSS Grid implementation is mostly feature complete at this point, but there are still a few bits of functionality (like baseline alignment) and a lot of testing that needs to happen before we are ready to put out a stable release. For those of you who are interested in using a CSS Grid implementation as a library in their own (non react-native) projects, we have put out an alpha release that you could play with today. And you can track the progress of the CSS Grid implementation in tracking issue (https://github.com/DioxusLabs/taffy/issues/204)
Those who are looking CSS Grid support in React Native specifically may be interested in RFC: Vision for Layout Conformance/Parity, which sets out React Native's vision for layout going forwards. As you can see, they have considered Taffy, but are not planning to adopt it in React Native. I also had some further discussion with @NickGerleman (who has recently taken over maintenance of Yoga, and has already been implementing some welcome and long overdue improvements to things like the build system) where it was explained that the primary reason for this is a strong commitment to bug-for-bug backwards compatibility in React Native's layout engine (on the basis that bugs caused by changes in layout will likely be silent and hard to detect) and a belief that it will be hard to maintain that if switching to a new layout engine (a belief I am inclined to agree with FWIW).
Thus, in terms of getting CSS Grid support into React Native, it seems like the best path forwards may be porting Taffy's implementation into Yoga. This is by no means a small task, and would involve refactoring the existing Flexbox implementation to interoperate with another layout algorithm (while maintaining bug-for-bug compatibility with the existing implementation - possibly behind a flag), as well as implementing the grid algorithm itself. But I think it is achievable with enough effort, and it would be aided by the fact that Taffy is a derivative of Yoga and that the structure of the two projects is still largely similar.
It would be amazing to see this materialize. CSS Grid is something the React Native ecosystem has wanted for a long time, and this thread has many other users of Yoga who would benefit from it as well. I have also suspected CSS Grid would be a valuable enough addition to React Native that we could use it as a tool to start driving users to migrate their apps to conformant behavior.
As I'm sure you can tell by the other thread "how can we do this safely" is very top-of-mind. These sorts of shifts have to be done piecemeal, but I do think we have concrete ways to do them. E.g. WPT fixtures for validating the conformance of new changes, or perf testing for any sort of major algorithm change (I don't have confidence the current tests would catch many real-world issues here).
My ideal would be for Yoga to be conformant by default. The fear of behavior changes has been a stall on Yoga's development that we need to move past, but we need to be smart about it.
The model I have been exploring for that is that we:
YGNodeLayoutAffectedByQuirkHave some work drafted to start doing this for
7e96b65790, addingYGQuirkAbsolutePercentageAgainstWrongEdgeandYGQuirkTrailingColumnMarginIncorrect.There are also some apps and frameworks inside of Meta which depend on the latest Yoga, but are no longer being actively developed. They won't see any benefit from the new things happening, and are one of the larger risk-areas to our own usage since they are more eyes-off, so I have been working to see if I can freeze them on an older version of Yoga to give a little bit more breathing room to make changes.
The stable 0.3 release of Taffy with CSS Grid was released yesterday. So it's now ready both for production usage, and for porting should anyone wish to take that on.
@NickGerleman
It has occured to me that the first step towards supporting CSS Grid in Yoga would be refactoring the flexbox implementation such that when it needs to measure children it is able to call into another algorithm rather than always calling recursively into itself. And if we're making this change anyway, I'm wondering if it would make sense to duplicate the flexbox algorithm into "legacy flexbox" (frozen in the current state) and "modern flexbox" (where we could go to town on the breaking changes - perhaps with an effort to get it quite close to standards compliant for the first release so that the breaking changes are mostly a one-off rather than an ongoing thing). This might be simpler than trying to feature flag everything on a fine-grained level...
Taffy uses this trait for this purpose, and in C++ you'd presumably want to use an interface. Making the algorithm logic generic over an interface provides two other benefits:
Taffy offers both a low-level API where the user of the library implements the above trait and handles things like caching and tree iteration logic themselves and a high-level API akin the one Yoga currently offers.
@nicoburns how can someone use taffy in react-native? It's not completely clear to me.
This is a joke.
Introduce CSS Grid for React Native. It's been 5 years.
Flex is cringe.
@rmacqueen @MoOx
I have no idea why you are both downvoting me.
It is absolutely ridiculous that this request has existed since 2015 and YET to be implemented.
With the previous issue on this, the representative from the Yoga team said he had "no interest" in working on it purely due to personal bias despite it being a highly requested feature.
CSS Grid smoothly creates responsiveness across all devices with pure CSS rather than trying to access the Client's window dimensions or use that garbage Flex which everyone doesn't like.
There's a time and place for overt positivity but this is beyond ridiculous.
With CSS Grid supported on React Native, I could enable complete responsiveness for my universal app across web, mobile browsers, tablets, mobile devices and desktop apps for mapped lists of data.
Instead, I have to use the garbage that is Flex.
So kindly don't downvote me if you have nothing to contribute to a TEN year old request which has thousands of people supporting its implementation.
You forgot to renew your react native subscription.
Upgrade to the pro license and they might prioritize this feature
I already paid Zuckerberg with 20 years in free personal data collection.
@scotthavalosman why don't you fork the Yoga and bring it to the community instead of complain about an open source project.
Hey @scotthavalosman, I get that this issue might be frustrating, but complaining without bringing anything to the table helps no one.
You’re showing up here acting like a child — that’s not how open source works.
People contribute when it makes sense for their project, company, or simply when they have time. Acting like this will never motivate anyone to help you.
If this is critical for you, step up: open a PR, propose actionable ideas, or make a solid case to inspire others to prioritize it. That’s how you lead — by creating motivation and engagement around what you want to see happen.
And let’s be real: your opinion isn’t the truth. Personally, I think CSS grid is one of the worst APIs out there — but you don’t see me yelling about it. I use flexbox, and if I need something else, I try to make it happen. I open discussions, stay open-minded, and work to convince people why something’s worth tackling. That’s the way forward.
Otherwise, please stop posting just to vent. We’re here to collaborate — not to babysit frustration.
@hlspablo I don't think I'm adept enough at doing that – But if you point me in the right direction or provide an action plan, I'll give it a shot because I desperately need CSS Grid support in RN.
@scotthavalosman try to start creating a css lib that offer the css grid surface api, but that uses flebox under the hood. I think in Yoga issues you gonna find in depth discussions about css grid implementation. The effort is massive and would introduce breaking chances all over the code. Maybe the solution would be a new rendeding system, based on Yoga, optionally offered with some flag.
@MoOx
What is your justification in believing CSS Grid is inferior to using flexbox?
CSS Grid provides immediate responsiveness, streamlined code, no window dimensions from the client, is flexible with minmax, and can easily be used Server-Side – pure CSS.
We are moving towards a future where people will build Universal applications. Write once, Render everywhere.
The device you are using will become largely irrelevant in the face of these new frameworks.
All that will matter is your screen-size and immediate responsiveness.
SSR + Universal App + Deploy Once, Render Everywhere is the future.
Supporting using Flexbox over CSS Grid is like a boomer supporting Cheques over Bitcoin.
BUT who knows – maybe I am wrong. Thanks for pointing me in the right direction. I will look into trying to solve it myself.
@FremyCompany
Hi Fremy,
I hope you are doing well. I see you are active on GitHub this year.
It is time to revisit this decade-old problem regarding CSS-Grid support.
Are you ready?
How much money do you need to implement it?
Name your price. Everyone has a price.
What's yours?
Reminder (from 2021, please read it), this issue is a feature request.
It is not a place for chatting and complaining.
Please refrain from commenting noise as it will bury earlier comments that have more useful information for someone who may be interested in contributing a way forward. I'm referring to valuable commentary like this one and the few comments after it which discussed taffy (an alternative to yoga which does have CSS Grid support) and how yoga could approach resolving this FR.
Please don't ping devs that were last active in these discussions in 2019 (and 2015 from the original issue).
If you want to pay someone to implement the feature, great! Go seek a developer that will do it (but please don't do that here), once the feature is working they can contribute a PR that might one day get accepted/merged, in the meantime you could use that fork.
Beyond that, I wouldn't expect your activity here is going to motivate anyone from the RN team to chime in with good news. It'll either happen eventually or it won't, I opened this issue over 6 years ago so I don't expect much movement.
If it's truly a deal breaker for you, fund the fork or if it's more affordable/convenient move to an RN alternative like Dioxus, Tauri, or whatever else is out there that appeals 🤷♂️
Those suggestions btw are not an invitation to further discuss pros/cons or preferences. I'm not interested in doing that here (nor is the bulk of users subscribed to this FR), I'm only directing you to more realistic alternatives where you can use CSS Grid today.
Please respect OSS etiquette, avoid whining and stirring up drama here, thanks!
@polarathene
Your post is entirely pathetic.
Tired of people like you on every GitHub Issue I read creating an artificial barrier to solutions.
Hey buddy, YOU opened this issue in 2019, what have YOU done to resolve the issue?
That's right. NOTHING. You clearly weren't looking for an actual solution and you clearly didn't want to fork out the cash to resolve it. You wanted to make it LOOK like something was being done which is typical of users like you who want people to respect "OSS etiquette".
What about the etiquette regarding the thousands of peoples' TIME you wasted, getting them to vote on this?
Don't police my language again. Thanks!
You're must be new here? (hard to tell as you've made your profile private).
Once there is sufficient comments in an issue the UI will collapse the middle of the comment history, which can require one or more interactions with a "Load more" button.
This is what it looks like for reference (already happened in this very issue itself):
Once comments are collapsed like that, they are "buried". So congratulations, your involvement here has actually led to what I was concerned about occurring.
The viewer would need to further interact to find the comments contributing more value, while the noise is our back and forth going on atm which isn't actively helping a contributor towards resolving this feature request.
Use your head please. If someone wants to offer their services here to do the work but requires payment, do you imagine they're silently subscribed here?
If they've interacted in the issue itself but not expressed an interest in paid work, and especially if their last interaction within the issue was 6 years ago, perhaps you shouldn't be pinging that user for unsolicited work?
Rather you should be using more appropriate platforms to find a developer that would like to do a task you're willing to fund. There's a variety of platforms out there for finding such developers, or you can try your luck with bounties which other users can also contribute funds towards.
I could be wrong, perhaps you'll get a response that is positive and you arrange payment and it's all roses from there on, otherwise, no you're not doing anything helpful, in which case these comments are unhelpful noise (most likely outcome).
Please engage via the proper channels, rather than triggering notifications for everyone subscribed here for updates ok? This issue is not intended to be used as a casual forum / chat, it's meant to be focused on the feature request. I appreciate that you're intentions are to help progress this request forward, but please understand that you're going about it the wrong way alright?
What, people that are experienced with proper etiquette for feature requests?
Many of us are subscribed to various issues, we all want updates on those that are worthwhile, not annoying notifications that are noise we have to sift through. Could you please learn to respect that?
Mate... read my issue description, it clearly states I was asked to open a new issue and so I did with additional context. It's accumulated enough reactions to show the interest in the feature is there far better than the other sources, the links to an external public feature tracker Meta once had is no longer valid but the demand is still apparent.
I've shared some information since then and tried to keep the issue focused, you're the first user in a while to not respect that for some reason 🤷♂️
Personally I don't use React Native anymore, but I am contributing to various projects quite a fair bit and my contribution history is public, so take a look if you don't think I do enough to give back to the community 🙄
Honestly...? This project is run by Meta, organizations like that aren't quite the same as typical OSS projects I contribute to and I'm quite familiar with how feature requests can pan out.
I recently contributed to another Meta project actually, but my PR was closed as they manage the actual source on another platform where someone else merged my contribution.
Generally though, I don't expect much action from large organizations when issues are open for as long as they are like this one with minimal public engagement. There was some activity earlier, and in my previous reply to you I did provide that information with links, something you clearly don't seem to appreciate despite that it's relevant towards what you want 😕
Uhh?
I opened the issue back in 2019 yeah? How am I meant to know at the time how it will pan out? The majority would have quickly understood that this is an issue you subscribe to and wait until a notification shows up that it's closed, or you follow along for updates.
Some of those users checking the updates are trying to let you know with their reactions that they'd rather this redundant commentary halt. They do not engage themselves in this discussion because they do not want to contribute to the problem that you've instigated here... notifying all those users that you're accusing me of wasting time 🤦♂️
I merely asked you nicely to be respectful of how feature requests on the platform work here, something you're not familiar with and seem to believe will play out differently if you act the way you are presently. I even tried to be helpful to you in my response, even though it wasn't to your liking.
A more likely outcome from the current activity here is that the issue will get locked and closed, preventing all subscribed users from receiving the more preferable option of someone chiming in with an update about an actual contribution of the feature.
As per my prior comment, I'd rather avoid notification spam to subscribers from derailing this feature request and the risk of causing it to be locked, so I'm bowing out after this comment and I hope you have the decency to do the same.