Any plans to support 0.76+

[enahum]

It’s been a while since version 0.74 introduced some breaking changes (I managed to find a workaround, though). However, with version 0.76 now available, it appears that there’s no way to make it work with jsi enabled.

Unless someone has a workaround, I’m curious to know if this is being considered for a future update.

[NikolaGrgic]

I doubt it.

I've personally tried to use this library numerous times and always run into errors that are highly difficult to debug, especially on the newer architecture. I've had multiple sessions that go on for several hair-pulling hours that that end up being resolved by resetting the React Native cache and deleting and reinstalling the app. This is simply a poor developer experience and there's no way around it. The most damning part is when you realize that there are no viable alternatives for WatermelonDB on React Native.

I considered contributing to this project to help resolve some issues, but I cannot find the time due to work constraints, and I'm concerned that, with how much of a mess this project has become, I simply won't be able to contribute effectively. For example, there are 23 PRs still open (some as far back as 2020) and issues that are flat-out being ignored, like this particular one.

I imagine the maintainers don't want to give up control of the repo, but they seemingly also lack the time to be able to effectively maintain and update this library. To clarify, I do not wish to put them down in any way - I'm simply calling it as I see it. I understand that people get busy (like myself) and they can't always contribute to open-source. Such is life, and I do not blame them.

I think, above else, that there needs to be a drastic way in which this project is maintained, especially when offline-first apps are a priority for so many people developing with React Native. I love the React Native community so much, and I certainly don't want to give any more reasons for people to use Flutter instead! 😅

As a result of everything, I wanted to put it out there that the minute I get a chance, I'm working on a full replacement for WatermelonDB that features:

• New React Native Architecture Support
• Full TypeScript Support
• Modern Practices + Simpler API (React Hooks, etc.)
• Better Error Handling
• Better Documentation

Let me know if you or someone else is interested in developing this.

[lucaswitch]

It’s been a while since version 0.74 introduced some breaking changes (I managed to find a workaround, though). However, with version 0.76 now available, it appears that there’s no way to make it work with jsi enabled.

Unless someone has a workaround, I’m curious to know if this is being considered for a future update.

The jsi mode is not needed anymore cause we have turbo modules stable now. In that way all library events and calls needs to be typesafe and be ported through codegen.

Also one thing that we have to keep in mind is to keep backwards support(the old bridge) until they launch a version that meta actually removes it completely.

One thing that broke WatermelonDb is actually not related with it at all.

The latest react-native babel preset does not work well with "babel-decorators plugin" which we depend heavily to addressing models.
Thats something that is already is fixed on new version 0.76.2, see facebook/hermes#1549.

For people having this issue the workaround is renaming all the models to .ts and enabling typescript experimental decorators support.

[angelo-hub]

if i had the time i'd do it, and basically use MMKV's pattern for observability

[angelo-hub]

sorry posted to early glad you guys are on top of this @lucaswitch

[elsa17z]

@radex said they were going to work on it in August #1769 (comment), no idea the progress, we are blocked by this library in upgrading to the new architecture as well.

[prathameshmm02]

This #1854 works on RN-0.76. But, if you are using Expo, watermelon will need to be manually linked, due to Expo's new autolinking, as watermelon-db's android and ios folders are located in native folder which Expo's autolinking doesn't seem to be picking up for autolinking.

[caiopratali]

This #1854 works on RN-0.76. But, if you are using Expo, watermelon will need to be manually linked, due to Expo's new autolinking, as watermelon-db's android and ios folders are located in native folder which Expo's autolinking doesn't seem to be picking up for autolinking.

Tnks!!

To use watermelondb with react native 0.76 and expo 0.52 set EXPO_USE_COMMUNITY_AUTOLINKING=1 in the android script in package.json, add @react-native-community/cli and set "experimentalDecorators": true in tsconfig

[radex]

Hi everyone,

0.28.0-1 now works on RN 0.74+ (Android/JSI). Note a small breaking change is needed for this -- see this comment for details: #1769 (comment)

Please let me know if this works for you on 0.75/0.76, and if not, what issues you're encountering.

— Radek

[CodeWithBlaze]

will this also work on the 0.76+ new arch and jsi enabled ? because i am getting strange errors like this
Caused by: java.lang.NullPointerException at com.facebook.react.runtime.BridgelessCatalystInstance.getReactQueueConfiguration(BridgelessCatalystInstance.kt:116) at com.nozbe.watermelondb.WMDatabaseBridge.invalidate(WMDatabaseBridge.java:251) at com.facebook.react.internal.turbomodule.core.TurboModuleManager.invalidate(TurboModuleManager.java:417)

when i reload the app

@radex can you confirm this please. Using pre-release version 0.28.0-1

[ALTHGA]

will this also work on the 0.76+ new arch and jsi enabled ? because i am getting strange errors like this Caused by: java.lang.NullPointerException at com.facebook.react.runtime.BridgelessCatalystInstance.getReactQueueConfiguration(BridgelessCatalystInstance.kt:116) at com.nozbe.watermelondb.WMDatabaseBridge.invalidate(WMDatabaseBridge.java:251) at com.facebook.react.internal.turbomodule.core.TurboModuleManager.invalidate(TurboModuleManager.java:417)

when i reload the app

@radex can you confirm this please. Using pre-release version 0.28.0-1

same problem!

[mobtex]

will this also work on the 0.76+ new arch and jsi enabled ? because i am getting strange errors like this Caused by: java.lang.NullPointerException at com.facebook.react.runtime.BridgelessCatalystInstance.getReactQueueConfiguration(BridgelessCatalystInstance.kt:116) at com.nozbe.watermelondb.WMDatabaseBridge.invalidate(WMDatabaseBridge.java:251) at com.facebook.react.internal.turbomodule.core.TurboModuleManager.invalidate(TurboModuleManager.java:417)

when i reload the app

@radex can you confirm this please. Using pre-release version 0.28.0-1

same problem 2!

[deeeed]

Same issue here. Is there a recommendation or official hack to use expo 52 / RN 76+? Should we disable newArchitecture? Even disabling it, would it work?

[roo12312]

any updates on this?

[MatheusHCP]

#1769 (comment)

with this comment i running Watermelon DB in Expo SDK 52 and RN 0.76 with new arch enabled.