The biggest problem I've run into with React Native has been their handling of issues. Far too frequently I'll google an issue I'm having and click a link to a bug report that matches the exact problem I'm having and provides a repro only to see that the issue was closed for inactivity. Never mind the issue is still valid, and the comments on the issue will ask for it to be re-opened and the response is to open a new issue.
So then you start this goose chase of hunting down the current issue since it starts getting into this loop of closed, open a new issue, closed, open a new issue, closed, open a new issue, etc. And everytime this happens relevant information gets lots because its not transferred to the new issue.
And then you finally find the newest, currently active iteration of the issue and find out that its still not fixed and the workaround is to stop using the React Native version and re-implement the feature yourself natively on both ios and android.
I remember asking about this on Reddit and got a response from someone on the RN team.[1]
> In practice this means that we have issues coming in, but we never close them when they are fixed, causing them to pile up. So we decided that the best thing we could do is mark them as stale and close old issues that nobody has commented on in a while. If we mistakenly closed something that is still an issue, the community will let us know and we can reopen it.
The discussion I had with them was interesting, but it didn't leave me feeling like anything would really change. Seeing your comment reminded me of this and I guess the status quo has remained.
I can't seem to understand what the problem with "pile up" is? The whole idea of logging issues is to see how long they're open for! In fact good projects take the painstaking exercise to coalesce tickets that are in fact the same with an original item IN ORDER TO track the correct age of the ticket.
most of the time the issues are also not fixed (a cross multiple releases)
some of the issues are really basic ones, one can wonder why they made a release with them in the first place.
The response that I've gotten, after complaining repeatedly, is that the team simply has no time to look at any externally reported issues, and that it's essentially a waste of time opening an issue.
This makes me very sad (as an ex-FBer especially), I wish that FB would just add another 3 or 4 engineers to the team with the explicit goal of giving them the bandwidth to be good open source stewards. I'm sure the FB engineers don't like having to ignore the community, but they do as a matter of policy.
They could learn a lot from Microsoft. VS Code, Typescript and related projects are a shining example of how to handle issues on open source projects. In fact, considering what heavy users they are of React Native, maybe Microsoft could be taking a more active role in the core project.
This is a great point. There have been a few issues that I've followed only to find that eventually the entire thread on Github with tons of example cases of the bug gets "closed for inactivity" because nobody from Facebook would respond to it.
They don't need to add more engineers - as an open-source project, all they should have to do is put one person to manage the community, encourage and vet new contributors. But that would mean losing some control.
I've found that to be relevant for a few issues (including one of my own) with Facebook Open Source projects—that or they just go unheeded by staff, but confirmed by a stream of others.
I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...
>At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company
That's not the case with React Native though.
The problem is that the surface area is vast, and the popularity is booming through the roof. If RN team looked at every issue, the (very active) development would stall completely. On the "web" React repo we can afford to do this because our surface area is much smaller, but on RN it's not practical.
So instead, the RN team tends to focus on the issues that are reported most often by the FB product teams. While this is not a great outside communication strategy, it ends up highlighting most pain points shared by folks outside the company too. Note this includes vast architectural improvements as highlighted in the post--something that goes way beyond a traditional GitHub issue report.
While admittedly this approach puts FB's needs first, it also serves as an important way to keep the team focused. It is very hard to deal with dozen new issues every day and still move the project forward so they chose this path.
I want to highlight that RN has maintainers outside of FB who help with different parts of the codebase (because again, the surface area is vast), sometimes with more expertise in those areas than people at FB. So the project isn't dependent on FB maintainers looking at issues alone. Folks outside can, and do help.
This doesn't mean issues don't end up being addressed in the end. But GH issue communication model just doesn't scale well for RN.
I'm one of the open source React Native maintainers here at Facebook, and I'm the one who has set the direction for how issues are treated on our React Native repository.
To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue.
If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com.
At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past.
We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons.
But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion").
Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized.
Well, I see there's at least been some action on the TextInput regressions that were keeping us on fork! <3
Not that running a patched version is necessarily a huge deal, but it's nice to have that 'this random code is approved by someone that actively works on the codebase' stamp.
(well, still might be on 0.55.3 for the version if NetInfo we can work around, but I do appreciate the project, warts and all)
There's a long tail of PRs to go through and review, and the ones we review may take a while to get to a point where they are accepted, but saying PRs are never accepted isn't quite accurate: https://github.com/facebook/react-native/pulls?utf8=%E2%9C%9...
I've had the same experience in multiple open source projects. Seems like not spending though resources on unsexy things, like QA, is typical for open source – although I'd rather expect it from volunteers than FB's engineering team.
Lots of negative or neutral posts in here, so let me chime in: I love React Native.
It’s not perfect, but it’s very damn good. One of the most impressive pieces of software I’ve encountered in 9+ years of mobile and full stack development.
I do all my projects in RN now, and I believe it gives me a 2-3x iteration speed advantage over my competitors with indistinguishable-from-native interactions (using react-native-navigation) and the ability to be on all platforms. For a solo dev, these advantages are insanely powerful and are the major reasons that my business is viable.
At 5k+ DAU I believe it is the largest production game written in RN.
There are more apps but I’m on mobile and it’s too hard to link them.
Major kudos to the RN team for all their hard work. RN makes me feel very dangerous as a solo developer and honestly makes mobile development more fun than I have ever imagined (especially paired with TypeScript). Thank you!
I tried your game on my Pixel 2, and aside from the performance issues already mentioned by other posters, there are very clear 1px misalignments (buttons borders, screen edges) that make it fairly clear (imo) the app is not native.
I don't have a lot of Android devices to test with, though it looks perfect on the ones I have. I would love to see screenshots of the imperfections you're talking about, it would be a huge help! If you see this, please send them to rawrmaan [at] gmail [dot] com. Thank you!
I will say that Android performance, especially in recent RN releases, has been one of my biggest issues with RN.
Everything about the game is highly optimized and performs beautifully (60fps) on all 2013+ iOS devices, but inexplicably performs very poorly on even some very new Android devices. I think it has to do with problems with the Android driver for Native Animated.
I've really enjoyed react native, and I dread doing application development work outside of it now. Many of the complaints in this thread are totally justified and reasonable complaints, but even with those issues I find RN to be the best platform to develop cross platform applications.
You've developed a fun little game but on Android it really feels 'out of place'.
The UI elements seem to be from iOS and performance is surprisingly poor for such a graphically undemanding game
I addressed the performance in another reply, but I would agree that it is surprising. And yeah, the UI is mostly iOS-inspired. Looking to bring it to more of a happy medium over time.
I haven't installed it, but I note that there's no explanation of what a "Picross / Nonogram" is on the google play page. So if I stumbled across this game I wouldn't have any incentive to try it out.
Given your background, maybe you or someone else here could help me. I am about to start a new mobile project, and I have yet to decide whether to use RN or Ionic.
My project will be nothing very fancy: mainly "forms" and use the camera and audio recording. But at some point in the future I would like to use hardware features more heavily (real time audio processing, GPS among others). Would you think RN would be a good fit for this? Have you had experience with Ionic? If yes, how do you think both of this compare?
I know that Ionic is not native, but I am more looking to understand how many headeches will I get to use the phone hardware on each of these two platforms.
I can’t comment on Ionic, but for the features you’re talking about, RN is definitely suitable. The RN ecosystem of native modules is certainly massive. Off the top of my head:
I'm curious, you use react-native-navigation. Did you ever try react-navigation? That's what we are currently using. Don't have any strong complaints, but know it does everything in JS. Was wondering if maybe you tried both and have any comments.
I haven’t tried a recent enough version of react-navigation to comment, but the older version was so bad in terms of complexity, missing basic features and inconsistent paradigms that I am permanently taste averted to ever installing the npm package again.
react-native-navigation appears to me to be the best available option. The main downside is that it kind of “takes over” your app in terms of the native bootstrapping process on either platform, which can make integrating other native modules slightly more challenging.
1) It runs very well without a network connection, you just can't access the online features. I've written my own syncing logic to make sure a user can experience the game for days or even months without having a network connection, and then have all their progress saved when they connect.
2) It works very well on low bandwidth connections. The puzzles are represented as strings and there are no remote images loaded.
3) For features that make sense in this game (sharing, IAP, haptics, notifications), it supports native functionality flawlessly. It is very easy to write native modules for RN, and there are may great npm packages that implement commonly needed native functionality.
There sure are some things to fix (Tutorial label placement on iPhone X, some buttons look blurry) and some behaviour that is not native (like the transition between screens), could be implemented but gives a clue that it might not be a native app.
Thanks for the kind words! Yup, fixed the tutorial button for the next release, and I should add @3x assets--I have poor vision so I forget about stuff like that.
On iPhone X, the placement of the tutorial button in the notch gives a non-native feeling. But a lot of existing native apps are also guilty of this. Otherwise, kudos, it is indistinguishable
Thank you! This is actually my fault and is fixed in my upcoming release. All of the other views are iPhone X optimized, which is quite easy to do in RN.
My largest issue with RN is that despite being "cross platform" there are numerous times it is not, and the documentation may or may not reflect this. From the image cache policy for remote objects not being obeyed on Android, resulting in all images being cached all the time (open for multiple years, never even acknowledged), to basic features like tiling an image just now coming to Android. Heck even making something as simple as the keyboard not occlude the field being typed into is not cross platform, with the docs just saying that some props may work better than others on android versus iOS.
That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.
React Native is partially magic, and JSX is really nice to work with. But the complicated things take minutes[0], and the simplest things take hours[1].
All that said, I'm still thankful to Facebook for putting out this project. Even if it does behave... weird at times.
[0] Networking? Stupid easy. Even if my linter is unhappy about 'fetch' not being declared anywhere. Great libraries mean things that are normally a nightmare, like, authentication become really easy. And the community has a to of tutorials.
[1] Want to make an image responsive? Or just learn how to render an image properly at all? It is the opposite of intuitive. Also React-Navigation is bad-but-getting-better to work with.
re: react-navigation, I am one of the two primary maintainers of this project and I started working on it in January of this year because it was in a pretty rough state. I think it has come a long way in that time even though there is still plenty to do. I would love to hear what simple things have taken hours for you when using it, feel free to reach out on Twitter in DM @notbrent or email brent at expo dot io. Also, the roadmap for our next major version is here: https://github.com/react-navigation/react-navigation/issues/....
Short summary is, well, the drawer is all sorts of weird. How the drawer interacts with everything else is also kind of weird. How to open a drawer with a NavigatorService is not something I could find documented outside of Github, and the comment there was old and what was suggested didn't work.
I have also seen people post suggestions on how to use the library that are just flat out wrong. Suggesting using props that don't exist (!!!???), and I've seen at least three recommendations of how to do lazy loading. Now that the docs are better these issues are going to go away, but unfortunately old blog posts (and github threads) live on.
Speaking of the documentation, it has gotten 10x better over the last few months. It has a ways to go, and pictures would be super nice. The React Native community likes to post Expo apps to showcase APIs instead of having super robust examples in the docs, I get why (and sample apps can be super useful!), but sometimes a "this option results in this" doc is super useful.
When I was first learning the library, some of the documentations labeled navigationOptions, some of them didn't and just passed it in positionally. It looks like the docs have been cleaned up, hopefully other examples around the web do the same thing. When I was trying to learn the API, this was very confusing, but I think if I had to learn it from scratch today, it would be a lot easier.
(If Steven Girder hasn't updated his examples, ask him to! His RN course is insanely popular and introduces a lot of people to React-Navigation)
So I guess saying it is bad isn't correct, but up until very recently, doing anything with the library was an effort in frustration just because of the documentation.
I'm still going to DM you some questions about the drawer though! :) (Update: answered, I was doing some things wrong, and Drawer is being rewritten to make more sense!)
> That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.
That just sounds like a poor understanding of dependency management.
Blindly running 'npm update' means just 'update all dependencies (respecting semver versions in package.json)'. You're going to have a bad time doing that, if you do it rarely, because a lot of stuff is going to update at once. The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
Sensible practice is to do something like 'npm outdated' (ideally in CI) to inform yourself of outdated packages and then manually update specific top-level dependencies judiciously, and re-run your test suite against them.
> That just sounds like a poor understanding of dependency management.
And yet a lot of tools and large packages will spit out an error telling the user to run NPM update. As someone who is new-ish to JS, I generally try and follow the recommendations of those who are supposed to know better.
> The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
I previously did C++. Breaking changes were few and far in-between. It helps when the library is only updated once every few years. :-D
Now days? Things that break in my environment:
1. Android Studio, I have never not had 2-3 hours of down time after an upgrade. Mostly involving...
The Android Emulator. After updates, it just doesn't start. This leads me to: The images on the Android Emulator. I finally have found one that works reliably, I am sticking with it.
Finally, Expo. It is just odd in places.
That is pretty much my entire development stack, short of my editor. Happily enough, VSCode updates just fine.
I have the RN debugger working more or less. There is a Cross Origin Resource error that occurs everytime RN opens up chrome, it opens chrome up to localhost, and I have to type in my IP address instead, which is a bit odd, but the debugger now attaches reliably, so compared to what it was like before, I'm good.
The Expo client is random. It tries to install Expo on the Android emulator all the bloody time, sometimes it works, sometimes it doesn't. I just want Expo to open. I have to use the client to open the emulator if my IP address changes, and this can take 10-15 minutes to jump back and forth between trying the command line client and the GUI client, eventually one of them opens my app.
And then if I login to my app too many times in the emulator, I max out the # of connections allowed to google's auth service and I have to shut down the emulator to close the connections or else I can't login again. I'm guessing it is a bug with how hot loading code works (not cleaning up open network connections?), but at least I understand the fix for it.
Basically the entire RN development stack seems like jank.
Also JS taking 5 minutes to compile blows my mind. I've compiled entire embedded OSes in less time than that (and they did more!).
FWIW I regularly (every month-ish) update all my dependencies in my native iOS projects (cocoapods) and it’s exceedingly rare that things break and when they do, it’s a matter of tweaking <15 lines of application code to fix. Stuff really only gets ugly if you go upwards of a year without updates, and even then it’s still somewhat manageable.
So maybe some library ecosystems are worse than others.
Having to delete node_modules to “fix” it is indicative of a poor package manager. Although not entirely the same, it reminds me of cabal hell, in Haskell many years ago.
I'm borderline infuriated that this isn't the default way that npm works. Maybe if people didn't willnilly break things and followed semver, it'd be okay, but I waste too much time bisecting why some package that used to work is blowing up my build or failing in less obvious ways.
But I'm a crusty almost-30 .Net developer used to Nuget.
Because that's not how it works. Subdependencies are still liable to slight shifting - of course there is the shrink-wrappish package-lock and npm ci, but they do some weird things I don't want to elaborate here.
It's not related to RN but you touched on something with NPM that made me realise that, for some reason, I never trusted its `update` command. If I wanted to update a specific dependency to a new version I would take the `apt` approach and just install it again, or tweak the version number directly.
Contrast this to how I've approached it in, say, Ruby...I'm very confident in blindly running `bundle update` and checking the diff to see the result.
I have been working on a commercial RN project for 2 years now. As of today, the project is ~50kloc, and provides builds for Android, IOS, Windows, and Macos platforms. I started it using RN after prototyping with an early Ionic2 version and checking Xamarin.
The code share between IOS and Android is very high, almost 100% (except a few simple home-made native components), and we are above the 85% of shared code between the mobile and desktop versions (mobile is RN, desktop is react-native-web + rewriting of several components on a Qt WebEngine with native versions of a few RN components rewritten in C++). The C++ part is actually very simple, and under 2Kloc. Note that we use Typescript everywhere on the React side, and we consider it very valuable.
Overall, everything works great, we have a few performance issues here and there, but nothing we can't deal with. However the biggest flaw is how indigent the build system is (combining all the flaws of npm and the issues of android upgrades), we still do not manage to have reproducible builds, and it's been sometimes very painful to fix an issue a few weeks later because it would just not build and require a few hours to make it build again.
So I just thought I would put my thoughts into this, I've been using React Native to create a number of Apps for a very large company for a few years now. These Apps are used out in the wild and I get to see them being used. As a codebase I think it's great - a really nice way of working and creating something. It's got great integration with tools and the general code setup is really nice.
However; If I'm being honest I don't think I've ever seen a worse managed project in my career. Each version that comes out seems to be completely incompatible with the previous one. Getting the App to simply run can take far longer than it takes to actually build the app. There is no locking of library versions so things conflict constantly. Often times the team will update React Native to use some new feature, this makes all backwards compatibility with Xcode incompatible. I think I drew the line when the advice was, just update your whole OS, download the latest Xcode, Yarn and then this latest version will work.
To be frank, it's infuriating - and I know it's not yet 'officially' released but if this is the state of how they plan to manage React Native in the future, I can't see much hope in it. And that would be a shame, because as a framework I think it's fantastic.
I never really understood the version numbering. It's still pre-1.0 and yet it's somehow production ready and encouraged. We're using React Native at work but I'm really conflicted about it for a number of reasons. As the sole mobile developer it's my responsibility to deliver our apps but something in the back of my mind doesn't sit comfortably pinning everything on a framework that isn't even v1.0 yet and it shows.
A few years back I was working with Titanium SDK to build apps in my spare time; so it was a pretty obvious choice for me to checkout React Native. It's pretty cool at first but once you dig a little bit deeper and try to tweak things here and there, add extensions, third-party frameworks, ..., the pain becomes very real.
In fact, I learned iOS app development using Swift & Xcode just to not work with React Native anymore.
> No updates but if you'd like to help financially sponsor the work to get this done...
For a project coming from Facebook, this is a bit rich. It's basically saying "you can pay us to build it for you," which isn't wrong, but it's not what you expect from filing an issue on an open source project.
What is very well known and understood with React Native is that Facebook has surprisingly limited resources to work on it, so Facebook developers mainly work on parts of React Native that Facebook uses. It's understood that if you have a feature or use case that Facebook also doesn't have, you should be prepared to contribute that yourself.
RN isn't maintained by Facebook alone. The surface area is vast, and there are many folks externally who help with different pieces that they depend on or care about. There's a few consulting companies that help maintain RN, and they need to earn money in order to be able to contribute to open source instead of working on their client's projects.
It's not unheard of to have "sponsored" issues. In this case though, none of the commenters on that thread work at Facebook. It doesn't mean the issue won't be fixed if no one sponsors it but if you care about it getting fixed sooner, you can send in a fix yourself or sponsor someone else to do that work.
The downside with those is that the build of JavaScriptCore is significantly bigger than the one React Native currently ships with. It's quite a big dependency to have in an app, and a shame Google doesn't expose the system V8 runtime on Android in the same way Apple does with JavaScriptCore on iOS.
React Native is hot garbage. I work on a commercial project and it's unbelievable that it can't even compile without hundreds of warnings. Talk about low quality development work.
And every few weeks I shudder to pull a new version, knowing something will have change that broke our builds.
Now let me tell you about debugging in poor network conditions. Ugh.
That doesn’t seem to be something I’ve seen any of the core contributors acknowledge and is often overlooked. As a relatively inexperienced developer it seems like a bad thing on the face of it but the builds still succeed... what’s the tradeoff?
I'm actually a native developer. I'm responsible for a framework that supplies the react app with features it can't implement on it's own (or can't implement efficiently enough). So when I do builds, I need to know if I have any build warnings in my code, but it's almost impossible to see mine in the mass of React build warnings.
It also makes me wonder how compatible react apps will be, for example one build warning about a deprecated iOS feature I inherited actually causes a crash on iOS 12. We have over 400 warnings from the react code alone, how many of those are future land-mines? Quality development dictates your builds have few, if any, compiler warnings. Even if they are things you know will never be a problem you fix them or adjust your warnings so they don't potentially obscure other, more dangerous warnings.
That's a good rule for any professional development project, but when you are developing a shared class library for other developers to build professional products from, it's far more important. The React team's failure to clean warnings makes me question their actual ability and commitment.
Readit News
So then you start this goose chase of hunting down the current issue since it starts getting into this loop of closed, open a new issue, closed, open a new issue, closed, open a new issue, etc. And everytime this happens relevant information gets lots because its not transferred to the new issue.
And then you finally find the newest, currently active iteration of the issue and find out that its still not fixed and the workaround is to stop using the React Native version and re-implement the feature yourself natively on both ios and android.
> In practice this means that we have issues coming in, but we never close them when they are fixed, causing them to pile up. So we decided that the best thing we could do is mark them as stale and close old issues that nobody has commented on in a while. If we mistakenly closed something that is still an issue, the community will let us know and we can reopen it.
The discussion I had with them was interesting, but it didn't leave me feeling like anything would really change. Seeing your comment reminded me of this and I guess the status quo has remained.
[1] https://ps.reddit.com/r/reactnative/comments/7wqxjy/why_are_...
This sounds totally backwards.
This is the problem. Why not close them when they are fixed?!?
This makes me very sad (as an ex-FBer especially), I wish that FB would just add another 3 or 4 engineers to the team with the explicit goal of giving them the bandwidth to be good open source stewards. I'm sure the FB engineers don't like having to ignore the community, but they do as a matter of policy.
I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...
That's not the case with React Native though.
The problem is that the surface area is vast, and the popularity is booming through the roof. If RN team looked at every issue, the (very active) development would stall completely. On the "web" React repo we can afford to do this because our surface area is much smaller, but on RN it's not practical.
So instead, the RN team tends to focus on the issues that are reported most often by the FB product teams. While this is not a great outside communication strategy, it ends up highlighting most pain points shared by folks outside the company too. Note this includes vast architectural improvements as highlighted in the post--something that goes way beyond a traditional GitHub issue report.
While admittedly this approach puts FB's needs first, it also serves as an important way to keep the team focused. It is very hard to deal with dozen new issues every day and still move the project forward so they chose this path.
I want to highlight that RN has maintainers outside of FB who help with different parts of the codebase (because again, the surface area is vast), sometimes with more expertise in those areas than people at FB. So the project isn't dependent on FB maintainers looking at issues alone. Folks outside can, and do help.
This doesn't mean issues don't end up being addressed in the end. But GH issue communication model just doesn't scale well for RN.
Ironically if you wrote this up as an issue in their tracker, I would surely have one more such experience when they closed it shortly after.
That said I complain out of love, because React Native is just awesome when it works.
To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue.
If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com.
At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past.
We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons.
But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion").
Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized.
PS: If you would like to learn more about how we prepare each release, please visit https://github.com/react-native-community/react-native-relea...
Not that running a patched version is necessarily a huge deal, but it's nice to have that 'this random code is approved by someone that actively works on the codebase' stamp.
(well, still might be on 0.55.3 for the version if NetInfo we can work around, but I do appreciate the project, warts and all)
I'm not unsympathetic to your claim but context matters. This is an enthusiasm problem. Not a community one
As an aside, who's really the man child? Hacker News users, or the ~50 year old man insulting/trolling them with that image?
It’s not perfect, but it’s very damn good. One of the most impressive pieces of software I’ve encountered in 9+ years of mobile and full stack development.
I do all my projects in RN now, and I believe it gives me a 2-3x iteration speed advantage over my competitors with indistinguishable-from-native interactions (using react-native-navigation) and the ability to be on all platforms. For a solo dev, these advantages are insanely powerful and are the major reasons that my business is viable.
Last year I rewrote my game Falcross in RN and I’m so happy with my choice. Seriously, check it out and see if you can tell it’s a “hybrid” app: [App Store]: https://itunes.apple.com/in/app/falcross-logic-puzzles/id500... [Google Play]: https://play.google.com/store/apps/details?id=com.rawrmaan.f...
At 5k+ DAU I believe it is the largest production game written in RN.
There are more apps but I’m on mobile and it’s too hard to link them.
Major kudos to the RN team for all their hard work. RN makes me feel very dangerous as a solo developer and honestly makes mobile development more fun than I have ever imagined (especially paired with TypeScript). Thank you!
I do see that the buttons don't align with what the OS displays but that's ok for a game.
What I do see however is that it performs VERY poorly on my Pixel 2. Which is pretty surprising considering there is not much going on on the screen.
Not a major hindrance for this kind of game, but still very noticeable.
Everything about the game is highly optimized and performs beautifully (60fps) on all 2013+ iOS devices, but inexplicably performs very poorly on even some very new Android devices. I think it has to do with problems with the Android driver for Native Animated.
I've really enjoyed react native, and I dread doing application development work outside of it now. Many of the complaints in this thread are totally justified and reasonable complaints, but even with those issues I find RN to be the best platform to develop cross platform applications.
My project will be nothing very fancy: mainly "forms" and use the camera and audio recording. But at some point in the future I would like to use hardware features more heavily (real time audio processing, GPS among others). Would you think RN would be a good fit for this? Have you had experience with Ionic? If yes, how do you think both of this compare?
I know that Ionic is not native, but I am more looking to understand how many headeches will I get to use the phone hardware on each of these two platforms.
Forms: tcomb-form-native Recording: react-native-audio GPS: react-native-background-geolocation Camera: react-native-camera
I'm curious, you use react-native-navigation. Did you ever try react-navigation? That's what we are currently using. Don't have any strong complaints, but know it does everything in JS. Was wondering if maybe you tried both and have any comments.
BTW, here is our RN app. https://itunes.apple.com/us/app/bunch-group-video-chat-games...
I (we) also love RN (most of the time :P ).
react-native-navigation appears to me to be the best available option. The main downside is that it kind of “takes over” your app in terms of the native bootstrapping process on either platform, which can make integrating other native modules slightly more challenging.
Your app looks fantastic, by the way!
How well does it run on an intermittent network connection with poor bandwidth?
How well does it support key native features of both operating systems?
2) It works very well on low bandwidth connections. The puzzles are represented as strings and there are no remote images loaded.
3) For features that make sense in this game (sharing, IAP, haptics, notifications), it supports native functionality flawlessly. It is very easy to write native modules for RN, and there are may great npm packages that implement commonly needed native functionality.
Consider your DAU +1
Glad you’re enjoying the game :)
Anyhow, the game is pretty fun!
That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.
React Native is partially magic, and JSX is really nice to work with. But the complicated things take minutes[0], and the simplest things take hours[1].
All that said, I'm still thankful to Facebook for putting out this project. Even if it does behave... weird at times.
[0] Networking? Stupid easy. Even if my linter is unhappy about 'fetch' not being declared anywhere. Great libraries mean things that are normally a nightmare, like, authentication become really easy. And the community has a to of tutorials.
[1] Want to make an image responsive? Or just learn how to render an image properly at all? It is the opposite of intuitive. Also React-Navigation is bad-but-getting-better to work with.
I have also seen people post suggestions on how to use the library that are just flat out wrong. Suggesting using props that don't exist (!!!???), and I've seen at least three recommendations of how to do lazy loading. Now that the docs are better these issues are going to go away, but unfortunately old blog posts (and github threads) live on.
Speaking of the documentation, it has gotten 10x better over the last few months. It has a ways to go, and pictures would be super nice. The React Native community likes to post Expo apps to showcase APIs instead of having super robust examples in the docs, I get why (and sample apps can be super useful!), but sometimes a "this option results in this" doc is super useful.
When I was first learning the library, some of the documentations labeled navigationOptions, some of them didn't and just passed it in positionally. It looks like the docs have been cleaned up, hopefully other examples around the web do the same thing. When I was trying to learn the API, this was very confusing, but I think if I had to learn it from scratch today, it would be a lot easier.
(If Steven Girder hasn't updated his examples, ask him to! His RN course is insanely popular and introduces a lot of people to React-Navigation)
So I guess saying it is bad isn't correct, but up until very recently, doing anything with the library was an effort in frustration just because of the documentation.
I'm still going to DM you some questions about the drawer though! :) (Update: answered, I was doing some things wrong, and Drawer is being rewritten to make more sense!)
That just sounds like a poor understanding of dependency management.
Blindly running 'npm update' means just 'update all dependencies (respecting semver versions in package.json)'. You're going to have a bad time doing that, if you do it rarely, because a lot of stuff is going to update at once. The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
Sensible practice is to do something like 'npm outdated' (ideally in CI) to inform yourself of outdated packages and then manually update specific top-level dependencies judiciously, and re-run your test suite against them.
And yet a lot of tools and large packages will spit out an error telling the user to run NPM update. As someone who is new-ish to JS, I generally try and follow the recommendations of those who are supposed to know better.
> The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
I previously did C++. Breaking changes were few and far in-between. It helps when the library is only updated once every few years. :-D
Now days? Things that break in my environment:
1. Android Studio, I have never not had 2-3 hours of down time after an upgrade. Mostly involving... The Android Emulator. After updates, it just doesn't start. This leads me to: The images on the Android Emulator. I finally have found one that works reliably, I am sticking with it.
Finally, Expo. It is just odd in places.
That is pretty much my entire development stack, short of my editor. Happily enough, VSCode updates just fine.
I have the RN debugger working more or less. There is a Cross Origin Resource error that occurs everytime RN opens up chrome, it opens chrome up to localhost, and I have to type in my IP address instead, which is a bit odd, but the debugger now attaches reliably, so compared to what it was like before, I'm good.
The Expo client is random. It tries to install Expo on the Android emulator all the bloody time, sometimes it works, sometimes it doesn't. I just want Expo to open. I have to use the client to open the emulator if my IP address changes, and this can take 10-15 minutes to jump back and forth between trying the command line client and the GUI client, eventually one of them opens my app.
And then if I login to my app too many times in the emulator, I max out the # of connections allowed to google's auth service and I have to shut down the emulator to close the connections or else I can't login again. I'm guessing it is a bug with how hot loading code works (not cleaning up open network connections?), but at least I understand the fix for it.
Basically the entire RN development stack seems like jank.
Also JS taking 5 minutes to compile blows my mind. I've compiled entire embedded OSes in less time than that (and they did more!).
So maybe some library ecosystems are worse than others.
Why not just pin your dependencies to specific versions, ie - “somepackage”: “4.2.9” ?
But I'm a crusty almost-30 .Net developer used to Nuget.
Npm is more fragile than it should be.
Contrast this to how I've approached it in, say, Ruby...I'm very confident in blindly running `bundle update` and checking the diff to see the result.
The code share between IOS and Android is very high, almost 100% (except a few simple home-made native components), and we are above the 85% of shared code between the mobile and desktop versions (mobile is RN, desktop is react-native-web + rewriting of several components on a Qt WebEngine with native versions of a few RN components rewritten in C++). The C++ part is actually very simple, and under 2Kloc. Note that we use Typescript everywhere on the React side, and we consider it very valuable.
Overall, everything works great, we have a few performance issues here and there, but nothing we can't deal with. However the biggest flaw is how indigent the build system is (combining all the flaws of npm and the issues of android upgrades), we still do not manage to have reproducible builds, and it's been sometimes very painful to fix an issue a few weeks later because it would just not build and require a few hours to make it build again.
Can you not use yarn?
However; If I'm being honest I don't think I've ever seen a worse managed project in my career. Each version that comes out seems to be completely incompatible with the previous one. Getting the App to simply run can take far longer than it takes to actually build the app. There is no locking of library versions so things conflict constantly. Often times the team will update React Native to use some new feature, this makes all backwards compatibility with Xcode incompatible. I think I drew the line when the advice was, just update your whole OS, download the latest Xcode, Yarn and then this latest version will work.
To be frank, it's infuriating - and I know it's not yet 'officially' released but if this is the state of how they plan to manage React Native in the future, I can't see much hope in it. And that would be a shame, because as a framework I think it's fantastic.
In fact, I learned iOS app development using Swift & Xcode just to not work with React Native anymore.
It felt to me like I was fighting with the framework every step of the way, swift on the other hand is an absolute joy to work with.
For a project coming from Facebook, this is a bit rich. It's basically saying "you can pay us to build it for you," which isn't wrong, but it's not what you expect from filing an issue on an open source project.
RN isn't maintained by Facebook alone. The surface area is vast, and there are many folks externally who help with different pieces that they depend on or care about. There's a few consulting companies that help maintain RN, and they need to earn money in order to be able to contribute to open source instead of working on their client's projects.
And every few weeks I shudder to pull a new version, knowing something will have change that broke our builds.
Now let me tell you about debugging in poor network conditions. Ugh.
It also makes me wonder how compatible react apps will be, for example one build warning about a deprecated iOS feature I inherited actually causes a crash on iOS 12. We have over 400 warnings from the react code alone, how many of those are future land-mines? Quality development dictates your builds have few, if any, compiler warnings. Even if they are things you know will never be a problem you fix them or adjust your warnings so they don't potentially obscure other, more dangerous warnings.
That's a good rule for any professional development project, but when you are developing a shared class library for other developers to build professional products from, it's far more important. The React team's failure to clean warnings makes me question their actual ability and commitment.