-
Notifications
You must be signed in to change notification settings - Fork 127
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
What do you dislike about React Native? #64
Comments
Upgrading requires a lot (too much?) effort |
Debugging exceptions I dislike that it's often not really easy to find the root cause of an exception. The stack trace in Chrome debugger console often leads to ExceptionManager and not the original place, which lead to time consuming debugging. Using componentDidCatch does not really help. Surprisingly, when we add a
#dx #debugging |
Not resilient to crashes It happens very often to me that I did something wrong and the app crashes (at least on Android) without a lot of informations about the cause. When it happens, Some examples:
I think it would be nice if RN was more resilient to these kind of errors, did warn with a clear error message and did not crash the app. #dx #debugging #crash |
Hot reloading Hot reload does not work great with Stateless Functional Components (SFC) currently. It would be awesome to be able to hot reload reliably any RN code without reloading the app, showing the splash screen etc... Tools like react-navigation persistance and storybook help to improve DX on restart, but having a functional hot reload would be the best. Not sure how hot reload will work with SFC including hooks but if classes disappear from codebase this may make the things worse. Doesn't it make sense to build a babel plugin to transform SFC to class in
#dx #hotreload |
Automatic Scroll on addition of elements at index 0 of ScrollView / Flatlist Adding messages on both sides of ScrollView/Flatlist shouldnot allow automatic scrolling. There should be a prop onPause to allow developers use it so as to disable automatic scrolling and remain on the same viewport on addition of messages at index 0. maintainVisibleContentPosition : When set, the scroll view will adjust the scroll position so that the first child that is |
Style, StyleSheet and optimizations Many of us think that StyleSheet API does optimize styles. But it never did and since 0.55 it's an identity function. It's not really clear to me how to write future proof styles today as I don't know the internal FB discussions about this API. Also want to mention that a lot of people do like to write styles inline, colocated to the markup, like the css prop of emotion of style props of glamorous-native. I think it would be nice to offer today an alternative to StyleSheet API for these people, and ensure this inline API will benefit the future style optimizations.
#dx #styles |
Debugging Debugging by running the JS in Chrome is a clever solution, but quite clunky. For example, it requires restarting the app, it causes problems with some native modules (e.g. react-native-gl cannot be included in an app you want to debug), and is not that useful for debugging performance issues as the JS is being debugged running on a different machine. Ideally there would be some way to connect directly to the JS running on the device while still using the great debugging tools provided by Chrome. |
ObjC / Java vs Swift / Kotlin I'm sure this one comes up a lot and I understand the scale of work that is needed to rewrite rn in these languages, however I found Swift and Kotlin much friendlier for people familiar with JavaScript. This can lead to more OSS contributions and custom native modules from JS devs, since learning curve of Swift / Kotlin is not as steep as ObjC / Java. Another side effect of adopting these as main languages is that documentation and new third party repositories will likely utilise them, so in general ecosystem becomes a bit more understandable for js devs. #dx |
No support for Ram bundle by any OTA platform Ram bundle is supported by latest react native versions but currently, it is not supported by any OTA platform like codepush. It will be great if we can have a more connected community and community-based feature prioritisation including third party libraries. |
Real time crash and performance monitoring tool Lack of official or community adopted real-time crash and performance monitoring tool, we do have tools like Newrelic mobile, react-native-sentry, bugsnag but none of them solves all the use-cases. |
Support of React Native team Would be nice to see a bigger involvement from react-native team to the community. #communitySupport Examples:
|
Documentation for library developers Currently there is not much documentation to help library developers aside from the introduction guides (iOS, Android). It would be good to have documentation for the full native API to make it clearer what classes and methods are available to use. These could be generated using JavaDoc and AppleDoc. |
Open Source Contribution Process The would work ok if releases were regularly made from the master branch, however, until the 0.58 release comes out the release process involves an additional step of asking for a cherry pick to be performed in the react-native-releases repository. For the casual contributor, this is not an obvious process and could lead to confusion and frustration about when a fix with an approved and merged PR is actually available in a release. This is compounded by the fact that the changeling doesn't directly reference the PR numbers and no comment is left on the PRs to say which release they are now available in. Related discussions: |
Metro follow symlinks Currently Metro does not follow symlinks, which makes it harder for the community to:
Related issue: #dx #packaging #symlinks #metro |
Native and React Lifecycle event mismatch Often have the issue while bridging that the ReactJS lifecycle events on the JS thread, are not consistent with the Native lifecycle events. We need more documentation on advanced and specific bridging issues. #bridge #documentation
Having a 1/1 on RN view/(ios-scene/android-activity) would probably fix this issue (and provide native navigation support?) |
Not having better official tooling for motion based interface User nowadays expect a lot more from apps than when RN was originally released and yet we still need to recur to the community or build from scratch solutions for motion based interfaces like shared element animation transitioning. #ux #animations #dx |
Missing documentation I feel like there are many hidden advanced features inside RN that are only documented in issues and that usage is found only in advanced libraries, without knowing if the API is official or stable. As a library author it could be helpful to have at least some doc on these APIs. I'm thinking of
#dx #documentation |
View Recycling React Native sometimes feels like it disrespects the platform by reimplementing basic functionality instead of providing a super thin layer to the mature underling platform stuff. For example, scrolling lists with view recycling. Android and iOS handle this differently. But both platforms do handle it. When writing a mobile app, I want to feel confident that I'm using the highest perf most mature stuff. That being said, I haven't used React Native for a while. For all I know, there may be some awesome view recycling built in for free now. It certainly could theoretically do a great job at that. And come to think of it I do vaguely remember something about that from however long ago. So maybe this is just a marketing/documentation thing? |
General Uncertainty. Lack of confidence The vibe I'm getting from some clients [citation needed] is general terror about the future viability of React Native. Some decision makers at some companies seem to be holding off on any investment in React Native. They've heard that it's being "rewritten". To them, that means that the current status quo is to be avoided like the plague. Seems like there needs to be some clarity in the messaging. Something to build confidence and certainty about the status quo and the long term viability of the platform. Some ammunition that engineers can use to get decision makers on board. |
Android emulation is bad It is a slow and ugly process to run an app through the Android emulator. The Android toolchain is a great effort, by much better developers than myself; but it's still slow and prohibitively expensive (in SSD space). I don't know what the solution is, here. Deeper and/or faster links to hosted emulation? Free devices for all? Who knows. Edit: this seems to be an unpopular opinion. I should clarify that; when compared to the speed, stability, and easy of setup of iOS simulator; Android emulation is years behind. I'm not saying this to be cruel or because I think I can do better. I'm saying it because it's demonstrably easier and better to develop strictly for iOS and ignore Android (even for the trivial case) because the only tooling available for Android is prohibitively poor in comparison. |
The solution to lots of problems is I think there could be better documentation around how to recover from the kinds of issues that are frequently resolved by a "fresh install". We could also codify the nuclear option as a feature of the CLI, so that Edit: it's clear to me that RN is overwhelmingly complex, and solutions like "fresh install" are the code equivalent of "turn it off and on again". The complexity isn't the problem. You're doing good work. It's just that I think we could understand root causes better, and help people get un-stuck sooner. |
Outdated dependencies One example would be ws, which is currently at 1.1.5, but needs to be at least 3.3.1, according to this. |
Performance, performance, performance First of all, I am an Android user. I don't use an old phone, I use Pixel 2 which is one of the top game. It's still noticeable when an app is in greenfield or not. Mostly, startup time. Startup time is quite crucial difference between pure native and RN. Not only when you open the app but for deep linking too. Imagine clicking an Android widget that opens the app, in RN the waiting time is just slow. You can mask that with a splash screen, brownfield apps, etc. But it's just a workaround. The feeling is not "native". One of the problems on this has been navigation too. I think the problem here is that Facebook probably just uses its own navigation system (native app that has some RN views). So they don't really need to help or invest in a common solution. That is a pity. When you develop an Android app or an iOS app, you don't need to care of navigation performance (mostly). It just works. |
Not keeping up with Android updates I have Android P. Border radius (ripple) and other stuff are broken. I can't see how this is not a priority. This give discredibility. You have your new shiny phone, new shiny OS but your RN looks bad. See for example: TouchableNativeFeedback's ripples aren't affected by borderRadius on Android 9 |
Database & Offline This is another topic. In RN docs there is just |
Orientation changes & landscape This is another topic quite ignored in RN in general. We just do not have a solution. Mostly RN apps are just locking orientation to portrait. A thing that is not recommended in the mobile world. |
PRs Mostly we believe is better to send a PR (solution) than open an issue. However, lots of PRs including mine, are just labelled and left forgotten forever. That just makes people stop contributing. |
Warnings in Xcode A lot of Warnings when you open react-native/ios app in XCode. |
I'll keep deleting comments here that do not stick to the template to make sure we can keep an overview. Please note that I am currently not looking for any more things to add to the already gigantic list, so please stop adding more items for now. Thank you! |
long release build time
android build time can be reduced too, but it's not so critical. |
@cpojer Since you're not adding items to the list, would it make sense to lock this issue? |
In ScrollView API there are methods like onMomentumScrollBegin and onScrollBeginDrag for beginning and ending different types of scrolling but only one onScroll for both types of scrolling. It would be helpful to have |
Virtualized list computes the blankness with wrong offset If you scroll down the list, so that it starts virtualizing the invisible elements, you can notice that after re-render, the elements change their positions. |
|
I want something like |
Can things like overdraws in Android be prevented with some kind of warnings? They ended up being a pretty big performance issue in our app and the solution was dead simple. |
I wish there was some kind of support for plugins like cordova does so i don't have to mess myself with android or ios project directly expecially when using external libraries that provide direct hardware access (react-native-*, video, sound, camera-kit, maps, etc.). Actually React Native, it seems to me, it is not providing much benefit for both native developer and for javascript developer. |
I'm working in Team of 2 people and having a lot of issues with working on the same project. I don't understand how to properly create environment so we can sync code between each other while working on the same project. Now, we create git repo with /ios and /android folder, but the thing is ios folder always need to be changed, because it links to the computer that was building the last. For example, we are working at the same time on different js files and add a new npm dependency and want to sync what we made together, so we commit changes and another one's downloading everything and now the pain comes. The one need to go to Xcode and manually update all the Framework Search Paths, Header Search Paths, delete and then add again libraries that Xcode don't see. |
@t3hfx your setup is obviously compromised, you shouldn't have references to relative path or things related to a specific pc setup. Learn how to use git and how to structure a project and you won't have these kind of problems. In any case the problems you described are not related to react-native itself. |
|
Thank you everyone for bringing all these issues to our attention. We've kept quite busy with our work on React Native in the past few months but we finally have a thorough reply for you, see #104 I will close this issue and ask you to comment on the other thread instead :) |
Edit: See our reply here: #104.
We, the React Native team at Facebook, would like to get a current list of all the things that people in the community are having problems with when using React Native. There are many discussions out there, and this has been done in the past, but let's have a fresh start and make a collection of things that we can then consider looking at in 2019. For now, we'll just make a list. Please don't expect any of these things to be prioritized and fixed right away. For me personally, this is helpful to learn more as I just joined the React Native team.
Please reply with all the issues that you are having with React Native. Keep your descriptions short and ideally link to other places with more context. Feel free to mention not just technical things but rather any issue that can be ascribed to the React Native project. Add hashtags if you like for easier categorization.
Please do not troll, rage, rant or insult people. Please do not comment here asking to merge your PRs or fix your issues right now. Open source discussions can get heated, but being angry about things won't help anyone make progress. If something has been mentioned already, please use the upvote/emoji buttons instead of repeating the same thing so that it's easier to see how many people care about each issue. Please make one comment per topic so that people can upvote just one thing at a time.
Hypothetical Example:
Not enough emoji
The React Native CLI barely prints any emoji and it reduces my satisfaction with React Native. I know that other members of the team have said they would enjoy using more emoji as well. Here is an issue that references emoji: facebook/react-native#22463 #emoji
The text was updated successfully, but these errors were encountered: