Turbo module / Fabric support (New Architecture)?

[mfbx9da4]

Is RN fire base planning to move to turbo module initialisation?

Thanks!

[mikehardy]

There are no current plans. I can say, having watched the progress of this as a member of the release-testers group - and seeing the pain it causes in for example the reanimated module, that it looks quite expensive to me, on the "module maintainership" side. So that's a negative: very high cost in new tech integration as it brings in new toolchains and requires module release cadence to sync with react-native release cadence - a significant new hurdle for all library consumers and a significant new dependency for release cycles.

If I understand correctly the sole benefit is that it is a performance optimization [Edit: this explains the benefits better, I'm still not sure they really apply to react-native-firebase, but it is important to understand them:https://github.com/react-native-community/discussions-and-proposals/discussions/546#discussioncomment-4160151 ]

In our case, I'm not sure there is any actual benefit to it for performance improvements with the exception of firestore, which could benefit perhaps from better performance in data marshalling/unmarshalling. But then it is my understanding that most of the performance issues people have had with firestore are related to local cached data being accessed slowly due to underlying issues in the native SDKs.

So to me I see large costs + a lot of added complexity and I see very uncertain benefits. Thus I haven't put it on my short list of things todo personally

Side note is that our testing infrastructure requires the JSI interface and I'm not sure that works when Fabric is enabled. So if I understand correctly, this is blocked until our e2e infrastructure moves to a pure on-device solution - that's something we have in progress but it's not done yet.

[affansk]

@dmahajan980 i may be wrong. i am not able to find exact merged pr related to it. but i just read on https://blixtdev.com/react-native-0-72-whats-new/

update : please check this : reactwg/react-native-new-architecture#115

[mikehardy]

That's fantastic! I have on my board to run new architecture compile tasks after seeing they were working on it for 0.72, I'll see if there are any gotchas, but in general this unblocks things here, fantastic news

[wkwyatt]

@mikehardy have there been any updates on this?

[mikehardy]

No updates at the moment, but we're quite active here in the repo. We're nearly done with the work to adopt the firebase-js-sdk v9 apis which was a higher priority but also a lot of work as it is an ecosystem shift similar to new architecture

Eventually we will have no choice but to adopt new architecture here of course, but the work has not really begun yet

[wkwyatt]

Is Firebase v9 natively compatible with the new architecture on RN? I am running into issues loading Firebase through cocoa pods as well as using the react-native-firebase lib. I know you mentioned this,
#6368 (comment)

So I wasn't sure if that was just for rn-firebase or for the Firebase cocoapod as well

[Nantris]

Any change on this? With new architecture moving closer to becoming the defacto standard, is it still not yet planned?

[bglgwyng]

#7688
It seems that New Architecture is now supported!

[TowhidKashem]

@bglgwyng can you please confirm it is? According to the main expo docs:

https://docs.expo.dev/guides/new-architecture/#known-issues-in-third-party-libraries

it's not :(

[bglgwyng]

I tested upgrading my app to new architecture but haven't tested all the firebase features yet. I think you'd better try new architecture + firebase yourself.

[BasixKOR]

I'm assmuming this has been solved by #7688, is it correct?

[younes0]

New architecture compatibility was announced by @brentvatne on this tweet https://x.com/notbrent/status/1832108444578672709
Thank you @russellwheatley & invertase team