+1

I dont think so they will. Looks like the community have to build a new package by wrapping native modules

From FB: "This SDK will now be publicly maintained by the developer community and Facebook will no longer release updated versions of the SDK. We are planning to move the current repo to our Facebook Archive on Github to allow the community to utilize the repo as a basis for future forks."

So I assume that goes for this package too.

Also from FB: "We will continue to allow API calls from your SDK for a transition period of two years. Starting January 19, 2023 we will fail all calls from deprecated SDKs. We encourage you to upgrade to v9.0 as soon as possible to avoid disruption to your application and to access all the benefits of our newest SDK."

So nothing to really worry about until the community picks it up.

I think fb will urge the upgrade, since the era of iOS 14 app transparency framework may cause some issue from their advertiser side :-)

+1

@johandeklerk could you please post the URLs to that content?

@thongncvn https://developers.facebook.com/blog/post/2021/01/19/introducing-facebook-platform-sdk-version-9/

+1

So there must be a fork (to be 100% clear: that is not any sort of political statement, facebook is telling us the community we must fork ;-) )

I guess the first job is to figure out who works on the project already, and/or if they are interested in continuing, in the general spirit of "those that do the work get to make decisions"

For more than a year, it has basically been the @janicduplessis show. So as far as I'm concerned that's the person I want to hear from with regard to future planning. Janic, do you have any thoughts? I can offer some help with maintenance but mostly (as with my prior PR here) with version tracking / dependency updates. I'm about at my limit with issue triage in other repos and can't imagine exposing myself to the issue triage flow here, honestly 😅

@janicduplessis @mikehardy I would just fork it, like we did with the rest of modules from community and then see how people are gonna participate.
And I can jump in helping with issue triage :)

Agreed the fork has to happen just that @janicduplessis may already have ideas (or may have preferences) with regard to github namespace / org and/or npmjs namespace etc. And by rights since he's been carrying the repo his preferences should get most weight in my humble opinion, so, I am still curious for thoughts

There may be considerations with regards to using the facebook mark, I don't know? Like, is an "react-native-fbsdk" org okay? with a "react-native-fbsdk" project etc, and are they okay handing off the npmjs "react-native-fbsdk" namespace for publishing continuity?

That's how I would do it if that was possible but I may be missing something that makes that less than ideal for some reason

+1
below that link FBSDK 9+
Version 8+ be deprecated on January 19, 2021. Have any plan to upgrade

+1

+1
so whats next for this? whats the next fork?

Is anyone actually paying attention? +1s do not help people. I think it's the right thing to do to see what @janicduplessis thinks. Has anyone else looked at the commit history? Do you realize it's been Janic and only Janic basically, for a really long time? I think if people are interested they should either 1) quietly fork and get to work. No on is stopping you! 2) listen here to see what Janic thinks first. It is NOT a burning fire of a problem.

Starting January 19, 2023 we will fail all calls from deprecated SDKs

There are 2 years to get this sorted out. +1s are useless and just spam notifications. Please don't.

@mikehardy can I plus one yours though ? 😅

Guys,

I modified the podspec and build.gradle files, changing the version to 9. It seems v9 has no breaking changes and the react-native-fbsdk works fine (I only use fb login)

I will run some more test and create a PR if everything works out

Hello !
I also modified version as @zhantx (but i'm only using AppEventsLogger) and I will do some tests. If everything will be fine, I will let you now and I will create PR (if it won't be exists yet)

I created a PR, I have tested the FB login and Graph Request on iOS and Android. All working fine
Also I believe @MateuszPrasal has tested AppEventsLogger

I created a PR, I have tested the FB login and Graph Request on iOS and Android. All working fine
Also I believe @MateuszPrasal has tested AppEventsLogger

I need few days to well test AppEventsLogger. I'll let you know :) Thanks for PR

Hope TypeScript is in the future plain of the new fbsdk, the current @type is just missing a lot and not growing with this repo.

Keep watching this for any update, I'm free to help if needed.

I'm wondering how we can export FBSDKLoginConfiguration FBSDKLoginTracking and FBSDKLoginManager. logInFromViewController in order to set FBSDKLoginTrackingLimited those are not available on android obviously. Currently ios sdk is using logInFromViewController in logInWithPermissions with FBSDKLoginTrackingEnabled by default. Maybe we will end up with something like this in the client code.

const result =
  Platform.OS === "ios"
    ? await LoginManager.logInWithConfiguration(["public_profile", "email"], LoginTracking.LIMITED);
    : await LoginManager.logInWithPermissions(["public_profile", "email"]);

Hello !
I've tested AppEventsLogger in SDK v9 (both Android and iOS) - everything work well :)

can i ask when this PR is merged ?

Fork or use patch-package until there is some repo-level understanding of who will maintain it going forward, where, and under what name @pratt3351

Looks like we're not going to have any position from @janicduplessis. I'm fine also to give some support on it if that would help.
Maybe we should try to contact someone at FB level and ask to transfer the repo/npm rights to publish new version on it.

The current version of the project will move to Facebook Archive. We recommend the community fork this repo into a new project that can be continuously maintained by the community. We encourage the community to make any necessary changes that they believe will enhance the functionality of the SDK moving forward.

Looks like we should start some movement towards fork and so on.

I just pinged @janicduplessis on the react-native discord server, just asking for either a statement with new info or a statement saying explicitly that no statement will be forthcoming :-). We'll see.

In the end it is open source, which is just to say that in the absence of any further info there's no stopping anyone from doing nearly anything on their own

Also, this was on the discord channel as some context from Janic directly as an idea for others:

I switched to using a ASWebAuth / chrome tabs based solution for facebook login as it is the only feature I was using from the sdk and it is a relatively large dependency. It is relatively simple to implement using react-native-inappbrowser-reborn
/ expo-auth-session. Not sure if we want to promote this more lightweight solution for FB login only implementations. I think using the SDK was more of a necessity before, but now all platform support good apis for oauth flows and seem to be the preferred way always even over using the native app if installed.

I've been basically only merging PRs to add missing features / update the native sdk for the past few years. I think there could be opportunities for a community fork / TS rewrite while making it more modular. The native libs are already relatively modular, but not the RN bindings.

I believe the JS part of it I would be able to rewrite into TS easily, but my main concern is maintaining the native part of it. Is anyone eager to help in such endeavor? I've forked it and plan to start some coding on weekend :)

I think I might help in Native side of it for IOS but may pour in some help for android as well.

@thebergamo How is the TS rewrite going? Me also has this in my todo list.

As a first step I wanted to make a new version available in NPM, so I've "forked" and renamed this repository and I've started migrating and also automating things based on the new repo.

thebergamo/react-native-fbsdk-next#1

I will probably try to implement structure for code of conduct and contributing guidelines based on react-native-firebase as I believe they have a quite solid structure there.

Please feel free to review and contribute.

@thebergamo from Invertase (the react-native-firebase folks) you might like this since you're starting sort of from scratch: https://docs.page/ - also I support all the E2E CI infrastructure in react-native-firebase and can attest that the .github/workflows are all pretty solid (literally as solid as I can make them - quite a few tricks in there) for running a test app in an iOS and an Android emulator. Some of it is react-native-firebase specific but I could collaborate on that stuff if you like. Hard to make that stuff not-flaky but it's critical for a large community otherwise maintainership is really difficult

@mikehardy that would be wonderful! After having this upgrade completed I would really appreciate it! Specially in the e2e CI.
It's been long time since I was helping in OS and looks like github has lot more nice features available :)

Feel free to use: https://www.npmjs.com/package/react-native-fbsdk-next :)

@thebergamo --> 🏆 !!

For anyone following along, I have test-integrated the release, here is what I had to do for a typescript project - pure javascript should be same except skipping the type stuff of course: thebergamo/react-native-fbsdk-next#1 (comment)