the whole point is to have native widgets and they are different. If you want them the same just use a webview

React Native is intended to looks like the native platform by default. If that's a negative to you use a different library.

I feel like it would still be good to have this option regardless, no?

I used to think It's an edge that flutter has, but lately I've realised it's a disadvantage. Having same looks on all platforms hurts UX badly.

Users need to have that "native feeling" when using the app and I guess that's the whole point of "Native" in React Native 😀

Think about it when the native alert dialog of iOS and Android are same-looking.

I agree. Because it's very hard to find a component that both works on iOS and Android...

Flex Gap is a huge addition to RN. Echoing my appreciation for the recent work there.

Some other gaps with CSS I find myself wanting regularly:

• fixed & sticky position

• Modern things like like mask and clip-path, as mentioned here

• Multiple shadows, as mentioned on the umbrella styles issue

• filter for things like blur(20px)

• All kinds of gradient backgrounds

Some other big ones:

• display: contents - really important for attaching events to child components you don’t have control over without changing flex behavior
• shadows not breaking with overflow hidden
• Multiple shadows

Bottom shadows only, without the need to wrap the element in a parent with overflow: hidden

Shadows that can be used consistently in android and iOS

Text outline support on both Android and iOS.

Solve this problem first, you drive quicker adoption.
Add other crazy features first, you cause segmentation.

Agree! But Expo does upgrade very good recently. I use one command, expo upgrade from expo 45 to 46. It works like a charm. Try it.

But not all companies use Expo. It would be convenient if React Native works in a similar way to Expo in terms of version updates. Upgrading an app with Expo is a delight. I can't say the same for React Native CLI.

I never use react-native upgrade because every project is different and I always do it manually by referencing https://react-native-community.github.io/upgrade-helper/. Lack of transparency in the upgrade process prevents using the upgrade command.

offer an easy way to get updates on the fly.

Changes to project.pbproj are very easily missed/ignored when upgrading, and even if notice them, 99% of the time, the changes are very hard to comprehend or apply. References are being moved around and they generate unique IDs, files are added/removed, build scripts are changed, it's just chaos for someone that doesn't have a very concrete understanding of how iOS development works.

If React Native wants to improve it's upgrade experience, this is the #1 issue to take.

the "tracker" is here: reactwg/react-native-new-architecture#6

Support legacy component in New Architecture app by a proxy or a virtualization layer. This will motivate people adopts the New Architecture much quicker and earlier.

Support legacy component in New Architecture app by a proxy or a virtualization layer. This will motivate people adopts the New Architecture much quicker and earlier.

This should get most attention tbf

Support legacy component in New Architecture app by a proxy or a virtualization layer. This will motivate people adopts the New Architecture much quicker and earlier.

This would be ideal. Any ideas on the technical feasibly of this?

@ltcaosj This could be amazing.

I maintain several libraries (react-native-{localize, permissions, bootsplash, etc.}) and don't really want to supports both architectures at the same time (at least, without a compatibility layer).
My current strategy is maybe to wait a bit until it's stable enough, ship a library new major version which is only compatible with the new arch. Users would have to stick to the previous version if they still use the previous one.

PS: It's currently quite hard to maintain RN libraries: The documentation is light (until recently, no guides for Kotlin / Swift), OS features evolves each year (the permissions changes, ugh), we often have to support multiple platforms: iOS, Android, but also the web, windows and macOS!

Focusing on maintainer DX could be a nice, necessary move.

FlashList is still missing native features such as the sectionIndexTitles as far as I'm aware.
(A-Z list on the right which allows fast scrolling trough a large set.)
https://github.com/aksonov/react-native-tableview came pretty far but isn't maintained anymore unfortunately.

react-native-tableview takes an approach that's good for performance, where list items are purely native components, controlled by props, instead of arbitrary complexity React components. So it gives you some styling options, and works for lists where items are just text and an image.

If React Native offered a similar API, would that fit the usages where folks are seeing perf issues? Or should we be spending the effort on lists which allow children to be React components?

items with dynamic height is a pain, specially trying to render initially a item on an index that it hasn't been already measured.

Ex: Say a list of 1000 items all with different heights (unknown heights like the posts in this discussion) and you want to render item 458 as the first visible item on the list.

https://github.com/jacobp100/react-native-tableview-list

react-native-tableview takes an approach that's good for performance, where list items are purely native components, controlled by props, instead of arbitrary complexity React components. So it gives you some styling options, and works for lists where items are just text and an image.

If React Native offered a similar API, would that fit the usages where folks are seeing perf issues? Or should we be spending the effort on lists which allow children to be React components?

We definitely want to leave React components as items. FlashList proofed that performant lists are possible(maybe with some constraints like fixed height), it's performance significantly superior to the FlatList.

Definitely one of the main pain points and something that a lot of devs coming from web development struggle with. On the web you have things like Profiler, debuggers, flame graphs etc. that are all helpful. On React Native issues with UI, animation, performance etc. can easily crop up and it's difficult to debug the root cause or measure improvements.

yeah react-native flipper is not compaitable with the latest version of firebase

You are not alone, every team/company i've ever worked with small to big has always had grievances with the DX experience ( a testament to how great RN is overall since they still use it ).

Debugging is hard. It's generally difficult understanding what went wrong, where in the code the error actually is and how to fix it. Not being able to debug properly ( including native side of things which is already arcane to most RN developers that aren't coming from a native background ) takes a lot of time.

P.S : Flipper also consumes so much memory as things are

Flipper uses many CPU resourses so I don't used this
I still always have Reactotron in background
I'd keep Flipper if background if it will not load CPU much (and will fork with Firebase)

Interesting. I need to learn more about flipper.

Metro team is working on pnpm support cite.

An explanation of the requirement is in this StackOverflow code example.

• Adding the contextMenu prop to the TextInput component [{title: 'remove', icon: myIcon}]
• Adding ReactEditText API setCustomSelectionActionModeCallback (an example of implementation on StackOverflow)
• Trigger a JavaScript callback as done with onAccessibilityAction.

Use react-native-svg or skia.

Use react-native-svg or skia.

But what about 2 & 3 points?

@AdityaPahilwani can you add links for the issues you mention for nested text and modal?

can you add links for the issues you mention for nested text and modal?

@kelset [a11y] Accessibility for nested text components #32004 (iOS)
facebook/react-native#32004

facebook/react-native#32004 (comment)

Please fix the Modal issues.

He may refer to the issue facebook/react-native#30097, which is fixed with facebook/react-native#34969. This comment includes a video and the explanation of the fix.

The parameters returned from the measure callback are calculated in TextLayoutManagerBuffer method measureMapBuffer. Changing the value returned in measureMapBuffer changes the callback parameters.

The functionalities are implemented as follows:

• measure callback is defined as a Spec of FabricUIManager.js (link)
• codegen generates native types for the measure Spec (more info in generator tests, parser tests, codegen implementation, generateMethods)
• The JavaScript implementation of measure is included in UIManager and FabricUIManager
• ReactFabric-dev.js adds the measure method to the prototype (ref) (more info in Eli commit)
• The JavaScript measure method calls the FabricUIManager.java measureMapBuffer (FabricUIManager => MountingManager => ReactTextViewManager => TextLayoutManagerMapBuffer)
• The measureText method in TextLayoutManagerMapBuffer already includes logic to calculate the position of attachments (inline images). A modified version could be used to calculate the position of nested text.

The measure callback is invoked from CPP to Javascript:

Paper (bridge) - MessageQueue dispatches calls between JS and Native
The previous solution used nativeToJsBridge, getRuntimeExecutor and RuntimeExecutor.

The runtime is managed by a JSExecutor, which is created by a JSExecutorFactory, which is passed in to the bridge when it is constructed. Each type of JS VM has its own executor factory (JSC, Hermes, etc.). The JSExecutor is owned by the NativeToJSBridge, which ensures that all operations on the JS runtime take place on the JS message queue thread. The NativeToJSBridge is then owned by the Instance, which interfaces with platform-specific code.

Fabric (bridgeless) - UIManagerBinding method UIManager::get calls the #measure callback with the parameters x, y, width, height (in the screenshot, frame.width and height are passed from CPP to JavaScript).
The measure callback returns 0 for Nested Text because computeLayoutMetrics always returns EmptyLayoutMetrics.
Adding support for Nested Text requires the following:

1. Implement similar logic to the one in TextLayoutManagerMapBuffer #measureText. The logic in measureText calculates the position of the inline images and saves them in the attachments array. The logic loops around each Inline Image and saves x, y coordinates of each attachment in the attachments array. The x, y coordinates are calculated based on the text and the inline image height/width (more info in discussioncomment-4998056) https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/text/TextLine.java;l=386;drc=caabd536e8fea82b888902f359b33e637267966c;bpv=1;bpt=0
2. Modify computeLayoutMetrics to return the values above instead of 0 (see the section above about EmptyLayoutMetrics).

Or this one: https://github.com/georstat/react-native-image-cache

Yes please! or at least have some way to do something like yarn link without having to hack your own solution together

Totally agree! More history for this issue: pnpm/pnpm#1252 (comment)

This should also help with monorepo support!

For those who are curious, the MSFT tool @todorone is referring to is: https://github.com/microsoft/rnx-kit/tree/main/packages/metro-resolver-symlinks 😉

I think this was also mentioned elsewhere, but the Metro team is working hard to close the gap. For example, support for the exports field spec is being worked on: #534

cc @huntie @motiz88 @robhogan

Everything you mentioned is being developed by the team at Meta.

We’ve started using Metro much more heavily at Expo. Expo just released beta web support for Metro along with the first ever native File System-based Router, built on Metro. These required some of the largest external contributions ever to Metro, which wouldn’t have been possible without the new Metro maintainers at Meta.

In regards to performance, Metro is actually so fast for subsequent bundling that it’s created an ecosystem which cannot be bundled any faster by other bundlers. Everyone ships untranspiled code in their libraries which must be bundled locally every time, this would take Webpack substantially longer and cause memory issues. Many other bundlers are fast by making assumptions about the web platform. We need better standards for library authors to ship transpiled code which the bundler can ignore, here’s an experimental look at how that might be done.

Metro is also leading the way in terms of subsequent bundling / advanced memoization. The general architecture of brand new bundlers like Turbopack are very similar to how Metro works.

But subsequent isn’t enough, production builds, CI builds, and many monorepo cases require fast initial bundling as well. Metro has a lot of room to improve here.

In regards to the whole native bundler movement. The Metro file watcher (watchman), is already native, the AST parser uses Hermes (WASM) parser (not on by default), and the transpilation could be swapped to SWC in user-space with a custom transformer, but due to the massive size (swc is ~58MB) it probably shouldn’t be added by default, this is why Vite uses Babel by default.

You can also swap the minifier over to ESBuild for substantially faster production bundling.

——

The future of Metro (over the last few months) has been looking really bright. We’re excited to help make it better at Expo. There’s still a lot of work to do, but fundamentally there’s nothing preventing Metro from being one of the fastest bundlers in the JS ecosystem.

Thanks for all the details! I'm looking forward to seeing metro get some love. It's been a source of pain for a long time and those pain points when solved by community PRs never got merged (6 years and counting on a PR for symlink support IIRC). If the project starts moving again it could make the react-native dx overall a lot nicer.

Excited to see Metro being pushed forward. I wish if the Metro team can also provide support for tree shaking in the future.

I would agree here. It doesn't go against lean core, you'd just be improving the implementation of the the provided image component

react-native-fast-image is great, but it has some significant memory issues on Android, which haven't been resolved. But yeah, improving Image component would be the most ideal

Yes, this is what I mean by maintaining it properly. react-native-fast-image has a number of open issues that still haven't been resolved... but even then the vast majority of the React Native community still uses it over the core Image component which is why I suggested bringing it into core. If there is a better way of improving the Core Image component well then great, that's up to the core development team to decide, but ultimately I think we just really need a rock solid Image component that handles caching properly out of the box. It's such a fundamental requirement of any app that we shouldn't need third party libraries.

@jamesxabregas definitely agree, assets management is an issue in React Native for sure

Totally agree, there’s a package for this: https://github.com/pie6k/react-native-dev-menu-on-touch

Edit: I'm going to unlock this conversation as we still have people contributing more areas of improvement and we do want to funnel this feedback to one area for easier lookup.

Although to clarify, since the survey is not actively open, please do not expect team feedback.

We are planning on doing this again next year. Once the 2023 survey comes out we'll also review any new comments here. Thanks!

Hey - I think a lot of your questions can be addressed elsewhere and aren't issues with RN. Try Reddit or one of the Discords etc.

Good point on third party support of all platforms though.

Well. I don't think this attitude helps RN improve at all. In other words, why doesn't Flutter have these problems while RN does?

You can also read this: https://stackoverflow.blog/2022/10/31/comparing-frameworks-for-cross-platform-apps-flutter-vs-react-native/

This blog said

Flutter always had what I needed and it worked perfectly. React Native pointed me to an NPM package and a Stack Overflow answer and said “good luck.”

Just describing some of my feelings during daily development

I was trying to be helpful to you and keep the noise down here at the same time.

You posted usage based questions and issues that can be answered. It's not about Flutter vs React Native or anything that's lacking in React Native.

The title of this channel is "How to Improve RN", so I compared and listed which places are not doing well.

Because I believe that many people have encountered the same problems I encountered. At present, these problems may eventually be solved, but the cost is much higher than that of Flutter, and it is not necessarily perfect.

I have raised and voted for many feature-requests on this site, but never got a response. If you don't like it, you can pretend I didn't say anything. But if we really want RN to be improved, we should pay attention to these voices and user experience

This adds on the build time of app

I'd say that the build time impact on the apps is negligible, at least on Android. Moreover, adding js-flipper as a dependency on the package.json will come with a cost at install time so the benefits on this point are limited.

Actually the main issue is the support for all devices. I don't think Flipper is currently at the stage, where we can easily connect iPhone devices (idb is really unstable in terms of discovering devices and be able to help exchange certificate), all Android devices (lot of time Samsung device would reject the certificated exchange)