Live reload often causes issues

When using Typescript I have to reload my app often when using live reload. It does reload, but it shows the red screen with "Unable to find module for EventDispatcher". It has done this for a while. This combined with hot module reloading not working very stable causes some frustrations in dev. xcode also logs a lot of noise. There are plenty of issues about these things, too.

TL;DR; I guess for me it's #devExperience?

No documentation for adding build flavours for both platforms

Currently react-native only ships with debug and production builds. Quite often in a development stage, the use of multiple builds (Staging, QA, Sandbox) is beneficial. Would be an opportunity to better describe and add tools (maybe for the cli).

When adding native code warnings aren't clear that a new build is needed.

When adding a module. Often reloading the bundle the warnings can be confusing. I think like with react-native, a warning saying native modules are out of sync with a bundle or need a rebuild would be a good developer experience.

Imports are not from root.

When setting up a react-native project all imports are relative. It's very common that a developer will add babel-plugin-module-resolver. I would like to see this done in a way by default.

Cold start warnings.

React native doesn't have a friendly way to track down which modules are causing long startup times. I often struggle to track down these issues.

Extend react-native cli to accept terminal commands

After starting the packager, I would like to be able to send commands to the running apps through the command line. It would be nice to accept commands for live reload, hot reloading, toggle debugger, and et cetera.

Doing so would improve developer experience, currently shaking the phone or using shortcuts to toggle the Dev Menu is a bigger hassle.

The available commands should be ideally displayed after you run react-native start

After dependencies are loaded:

Metro Bundler ready.

Loading dependency graph, done.

To hot reload press "r"
To restart the app press "R"
To toggle debugging mode press "d"

More commands could be included...

Expo!!!

Seriously the fact that you have to use expo to get this up and running is not cool. Don't get me wrong I like expo but it is usually very heavy so no matter how simple your app is, it will always be 20mb or more

Android JSC Crash

facebook/react-native#24261

Assets for all resolutions are bundled with the app

Right now we can specify images for various screen resolutions by appending suffixes like @2x and @3x to their filenames. This gives benefit of performance on lower end / low res devices, but at the same time increases app size since all of these assets are included.

iOS solves this through combination of asset catalogs and bytecode enabled builds, where app store serves versions with correct image resolutions based on user device. (I'm not sure if android has something like this).

It would be awesome if we could still keep images in one place and use those suffixes as well as optimise our bundle / apk sizes.

Metro Symlinks aren't supported by default

We need symlink support to do a lot of things. For me, it's a major headache trying to to develop package dependencies and work with Lerna monorepos without this support. There are currently a few workarounds that the community has shared, but none are one-size-fits all, and it's a major time suck to finesse a fix that works for your specific use case. This should really be something that everyone can leverage out of the box.

Lean Core is great but extracted repos may not be well-attended

I believe Lean Core is a great idea. But I have seen some projects that were previously extracted become inactive. People can get responses quickly from the main repo but not from those repos residing in react-native-community.

Current disappointment:

• react-native-community/react-native-push-notification-ios has a serious issue so you cannot even use pod install to use it now and the pull request has not been taken care of.

Swift not being the default language for iOS

It would be much better for JavaScript programmers (at least for me) to quickly navigate through iOS source code written in Swift than Objective-C which lacks readability compared to the other languages (Java, JavaScript ...). Besides, many examples concerning iOS are now written in Swift. Encouraging Swift in RN projects can make it easier for developers to debug native code or make their own (common case: add custom logics into lifecycle functions).

I personally would like RN to:

• change the default cli generated template from AppDelegate.m, AppDelegate.h and main.m to .swift implementations.

  Flutter cli does give you the option to generate Objective-C & Java template or Swift & Kotlin one.

• encourage new community libraries to be written in Swift for iOS. Rewrite of existing projects would be awesome too!

Linking native modules

This is by far my greatest pain point. I know it's up to the developers of native modules to provide linking instructions and maintain the libraries, but I feel that there could be improvements there.
For example, if there was a mechanism exposed by react-native-cli that would enable maintainers a clean way to inject code and assets into the native project, it would make things much more consistent.
react-native link should do the trick, but in practice it fails more often than not, and running the command twice causes even more complications. Then we're stuck going through the module install docs, and fixing stuff line by line.
On Android it's mostly adding some permissions to the manifest, build.gradle, checking minSdk versions etc. A lot of that could be done programmatically if only there was an API exposed by rn-cli. For custom stuff like API Keys, custom configurations etc. an interactive shell could prompt the user to enter the needed data.

Shaking to get to dev menu

I'd love if there was an option to configure another way to get to the dev menu. Expo has a cool feature with having a menu in the notification bar. I wish this was the case with react-native init

Documentation on creating a wrapper for iOS and Android SDKs would be great!

This might not exactly be the feedback that you are expecting, but the fact that when child has elevation, and you animate alpha of the parent, the elevation alpha does not animate in Android P (facebook/react-native#23090). This requires me to constantly write hacks in my app and really is the thing that hinders me the most on a daily basis

Navigation Library

React Native doesn't have a proper native navigation library built in! It should have a native nav implementation where all of its animations etc could be on the main thread, dont have to block js thread.

Hot reloading

Hook incompatibility with hot reloader

Unify dev tooling between pure and expo

Currently the expo tool chain seems to have so much more love, not asking for expo SDK stuff, but simple things like the webpack config, debug menus, developer UIs with metro etc.

It’s so much nicer with expo and maybe sharing some of that sugar back to pure will be a nice addition ❤️

Random build errors / lack of troubleshooting documentation

I very frequently run into random build errors like

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_RCTSRWebSocket", referenced from:
      objc-class-ref in libReact.a(RCTInspectorPackagerConnection.o)
  "_OBJC_CLASS_$_RCTReconnectingWebSocket", referenced from:
      objc-class-ref in libReact.a(RCTPackagerConnection.o)
ld: symbol(s) not found for architecture arm64

etc. (see facebook/react-native#15838). The linked issue is almost 2 years old and I had this issue 2 days ago on 0.59.8. I assume this is some build step thing and not directly related to react-native as such but more on how its dependencies are handled by xcode/cocoapods or something, but to me this is the most annoying thing developing react-native. You end up spending far too much time trying to fix non-application errors like this. And I realize its hard for you guys to debug since its most likely very stateful and hard to reproduce, but I think there is a huge lack of troubleshooting/best-practice guides around building/running.

E.g. dealing with Cocoapods have been a huge pain for us. And the actual documentation about it is a small subsection of another topic (Integration with Existing Apps). I think a lot of react-native developers are confused about these things because we come from web. My first experience with xcode/cocoapods have been with react-native. There are no "this is how to set up cocoapods inside xcode, this is how to deal with common error a,b,c, this is how to reset everything when all else fails" etc. A lot of times it feels like you cannot develop react-native in the long run unless you are already skilled with xcode and the ios ecosystem

Hot reloading

Fix hot reloading to work reliably with hooks and state support.

It was one of the things that made me love react-native a few years ago and it's been broken for a while. I see Dan has been working on it which is super great, hopefully it gets released soon.

Flatlist Component

There are 69 open issues related to this component (Some duplicated). Some issue related to Flatlist is opened since 2017. The bug is still present in the latest version. https://github.com/facebook/react-native/issues/16067
I wish the bug is fixed before releasing v0.60 stable. If we can resolve this component most of the issues is solved.

Slow TextInput is still a thing

facebook/react-native#20119

macOS support via Project Catalyst

iOS apps will be able to run natively in macOS. Currently the build doesn't pass. React Native only needs to make sure the build passes as the first step.

#131

FlatList performance

FlatList isn’t performant as it is advertised. It’s more like a workaround for long ScrollView. I was so hyped with Sophie’s blog post last year about Fabric and potential UICollectionView / RecyclerView interop, but it seems that it’s still not possible as of now

@punksta Yeah Native components can not use because Flutter does render components to Skia Canvas. But we can use whole flutter components library and render them using RN. Instead of rendering to Native components and reconcile we can do it to Skia canvas. We can use Core RN and use different render targets. Then core will be slim too.

as a reactJS developer, the experience with RN was non developer friendly, debugger doesn't work properly, no easy way to do things. Super painful.

Really big problem with React is the wide stack of technologies: Js, java, ObjectiveC, Gradle, shell scripts etc.
If you have some issue, there is only way to fix it: Known everything and spend a lot fo time. Most of people don't know so much and do not have a time to dig in.

As result we have:

• As rule the ignorant reaction to bug reports. Close and forget without any analysis.
• A lot of side effects (see my reset-all.sh script below)
• Low quality native /script code
• Same bugs again and again. 58 fix issue, 59 bring it back, 60 fix issue 61 bring it back.
• Upgrades are really painful. Hard to find incompatibilities.

What we really need is the troubleshooter/KB tool.

• Check and fix common errors.
• Warn about incompatibilities
• Option to clean up project (like my script below)
• Registry of trouble checkers (to avoid frequent updates)

#!/bin/bash
# clean react-native
    echo 'clean watchman'
    watchman watch-del-all
    echo 'clean node_modules'
    rm -rf node_modules
    echo 'clean caches'
    rm -rf $TMPDIR/haste-map-react-native-packager-*
    rm -rf $TMPDIR/react-native-packager-cache-*
    rm -rf $TMPDIR/metro-bundler-cache-*
    rm -rf $TMPDIR/react-*;
    rm -rf $TMPDIR/haste-*;
    rm -rf $TMPDIR/metro-*;
    rm -rf ~/.rncache

    rm yarn.lock
    rm package-lock.json

# install
    echo 'start'
    npm install
# thrid party module can install old 2.*.* version of cli, produce build errors in gradle
    rm -rf ./node_modules/react-native-cli

# clean xcode
    xcodebuild -project ios/MyProject.xcodeproj -configuration Release clean
    xcodebuild -project ios/MyProject.xcodeproj -configuration Debug clean
    echo 'clean Xcode/DerivedData'
    rm -rf ~/Library/Developer/Xcode/DerivedData
    echo 'clean ios build'
    rm -rf ./ios/build
    rm -rf ./ios/Pods

    cd ios
    pod deintegrate
    pod install
    cd ..

# clean xcode
    rm -rf ./android/app/build

# clean js build
    rm -rf ./build

Absolutely agree @ifyapishore. Stay tuned. react-native doctor is coming soon!

@ifyapishore Many people are working to make the native tooling easier and more transparent and/or hidden. I think RN is a big project, very involved and with big aspirations. In many ways it's still early and in others it's mature. Tooling still needs work and is actively worked on.

Personally, I am happy about your comments on that, and I am keeping it in mind while I work to make xcode integration easier. I don't appreciate the comments about RN being dead. 😬 All good though, there's plenty of proof it's not even close to dead. 🙃

I hate the fast refresh feature. I'd've preferred to have both hot reloading and fast refresh, so user gets to choose his poison. Missing Hot Reloading so badly. :(

I think the comments have addressed most things but I haven't seen this addressed:

• A lot of side effects (see my reset-all.sh script below)

"npx https://github.com/pmadruga/react-native-clean-project clean-project-auto" and done ;-)

I swear by this CLI plugin module. Most people miss DerivedData and this one (or your script) gets it, which is key.

@karthik-balasubramanyam15 - do you mean that you are missing live reload? fast refresh is like hot reload but it works a lot better

reRendring

@brentvatne No, I mean before, it used to be like if you just want to update styles in a modal then you enable hot reloading and just edit and save changes and it would reflect instantly. But now with fast refresh, it refreshes the all the props too, like for instance if I am on a modal which opens when you click a button in a component, then fast refresh would refresh the props, componentDidMount would be called and the modal disappears and I have to again click the button to see the changes.

And this gets much worse if your component has menus and sub-menus and based on some item in the submenu, the modal is rendered. As the tree structure gets more and more complex, it takes longer to navigate and see the changes you made, and you know with UI design changes its not gonna happen in 1 go, so I just wish they had both hot-loading and fast refresh features and let the user decide which he wants for his app.

Maybe its just me, maybe I am facing difficulty since I'm a beginner, maybe there is some other way I can achieve what I am looking for, any advice would be much appreciated.

@karthik-balasubramanyam15 State can only persist between hot updates if you use function component with hooks. So if you refactor the critical paths it should be ok.

My qualm with fast refresh is that it refreshes the whole app if there are exports in a file that are not react components. I do sometimes have some extra helper exports that don't change often (such as GraphQL fragments, etc), and it would be great to force fast refresh to not do a global refresh (perhaps a comment at the top of the file or something).

@jfrolich Alright, I'm gonna give it a shot! Hopefully, it will solve all my problems. Fingers Crosses!

As @jfrolich correctly says earlier, Fast Refresh will preserve state when a file you're editing only exports React function component(s). We've chosen this tradeoff because it's the only way for the feature to actually work reliably. If you search for issues, you'll find hundreds of comments about the old "hot reloading" failing to update the screen or causing bugs. If there's a particular part you're editing that you don't want to re-mount, extract it to a function component in its own file, and it will work.

My qualm with fast refresh is that it refreshes the whole app if there are exports in a file that are not react components

This is not correct btw. Fast Refresh doesn't "refresh the whole app" in this case. It just applies the same logic a level higher. So if Button.js exports more than a React component (e.g. some fragment), but is imported from Form.js and Modal.js both of which only export function React components, the state of Form and Modal won't be destroyed. In other words, the more function components you use, the less likely you'll lose state on edits. It is necessary to update "a level higher" when your file exports something other than a component. Otherwise, different components using that export wouldn't "see" the change.

This is explained here: https://facebook.github.io/react-native/docs/fast-refresh#how-it-works

This is not correct btw. Fast Refresh doesn't "refresh the whole app" in this case. It just applies the same logic a level higher. So if Button.js exports more than a React component (e.g. some fragment), but is imported from Form.js and Modal.js both of which only export function React components, the state of Form and Modal won't be destroyed. In other words, the more function components you use, the less likely you'll lose state on edits. It is necessary to update "a level higher" when your file exports something other than a component. Otherwise, different components using that export wouldn't "see" the change.

It does do a full reload in my app, it doesn't only wipe the state (which would be fine). Perhaps this is because the component is the highest level react component in the tree. I use react-native-navigation so every screen is a react root.

It would be great to prevent a full reload of the app (and just wipe the state) even if the change occurs at at the highest level in the hierarchy. (This might be a bug in fast-refresh BTW! Happy to provide more info for a reproducible example)

Edit, it might be this scenario:

Finally, if you edit a file that's imported by modules outside of the React tree, Fast Refresh will fall back to doing a full reload. You might have a file which renders a React component but also exports a value that is imported by a non-React component. For example, maybe your component also exports a constant, and a non-React utility module imports it. In that case, consider migrating the query to a separate file and importing it into both files. This will re-enable Fast Refresh to work. Other cases can usually be solved in a similar way.

Ah I think the top level screens within react-native-navigation will always run into this because the components need to be "registered" as a screen when the app is starting up (before the navigator is started), that means that there needs to be an import of the file containing the component that registers the component to be available in react-native-navigation. There is no way to prevent this import. The only way around is to for every screen render a "shell component" that renders another component (in another file), so the second component will fast-refresh.

Would it be possible to disable the import check for certain files preventing a full-reload? Or prevent a full reload in all cases in the settings if you don't care about potential inconsistencies.

if I separate style in an external style.js file I cannot use fast refresh during development, this can save bunch of time. any hint or way for this ?

need a high-performance list component

React-native 0.60 is having serious problems importing some modules like styled-components making these necessary modules inaccessible for development.

And with the debugger switch on...

Caused by this line:

import styled from 'styled-components';

Easy upgradeability

In react-native upgrade docs, it tells I could upgrade rn version using react-native upgrade but it fails every time when I try just because I modified ios project files to import my fonts to react-native. There is no way to automatically upgrade rn version.

Background Tasks

Due to the single thread nature of JS, some long running operations have been blocking the UI. I am not entirely sure if this would be like React Concurrent mode, as I would be talking about sending messages and responses to and from a different JS Thread. Right now there is a hacky way with a webview but I am talking about RN supported threading.

Very complicated for new learner because they have to do lots of configuration like small ex : for vector icon.

Non-standard CSS styling requirements

Makes it extremely hard if not impossible to adapt UI frameworks such as Semantic UI, grommet.io, and material design frameworks to work with React Native.

I think it would be ideal to work with the web standards committees to come up with a standardized way to do modular CSS in web and mobile apps, analogous to how JSX is standardized to support SPA libraries and how PWA is now a standard.

We'll be posting a follow up soon and address some of the issues raised here. Locking the issue for now, as I'm in the process of compiling the response at this time.

Thanks for all the feedback here. Our team has been internalizing and operating with this feedback for a while, we just forgot to close this issue.