Skip to content
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

Any plans to support 0.76+ #1851

Open
enahum opened this issue Nov 9, 2024 · 12 comments
Open

Any plans to support 0.76+ #1851

enahum opened this issue Nov 9, 2024 · 12 comments

Comments

@enahum
Copy link

enahum commented Nov 9, 2024

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
Copy link

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
Copy link

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
Copy link

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

@angelo-hub
Copy link

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

@elsa17z
Copy link

elsa17z commented Nov 19, 2024

@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
Copy link
Contributor

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
Copy link

caiopratali commented Nov 22, 2024

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
Copy link
Collaborator

radex commented Nov 29, 2024

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
Copy link

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
Copy link

ALTHGA commented Dec 7, 2024

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
Copy link

mobtex commented Dec 9, 2024

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
Copy link

deeeed commented Dec 24, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests