search

invertase / react-native-firebase

🔥 A well-tested feature-rich modular Firebase implementation for React Native. Supports both iOS & Android platforms for all Firebase services.
https://rnfirebase.io
Other
11.69k stars 2.21k forks source link

🔥v6 Notifications and Messaging Tracker Issue #2566

Closed technoplato closed 4 years ago

technoplato commented 5 years ago

[Updated 2019/12/09] by @mikehardy & @Salakar - so don't blame @technoplato for these words :wink:

This issue is just to track the status of v6 notifications and messaging module.

Currently notifications is not available in react-native-firebase v6, and will not be. Why? https://github.com/invertase/react-native-firebase/issues/2566#issuecomment-541109278

You may not mix react-native-firebase v5 and v6, so if you want react-native-firebase notifications, you will not be able to use react-native-firebase v6.

This has the most current status: https://github.com/invertase/react-native-firebase/issues/2566#issuecomment-562700412

Options are:

If you have any questions please read this thread. If your question hasn't already been answered please feel to raise it as an issue on the new Notifee repo.

Patience is always appreciated, and in the meantime react-native-firebase v5 continues to work and be updated.

technoplato commented 5 years ago

From this Tweet, looks like there's some good progress happening: https://twitter.com/elliothesp/status/1166651845873479681

Would still love to know where I could contribute to this great project!

mikehardy commented 5 years ago

I think this is the correct place, however with the tight deadline for the firebase conference happening, and the large-scale work from v5 to v6 I think it's mostly @Salakar and @Ehesp doing the v6 ports as a tight crew. As soon as that lands on the v6 packages though, there will be an immediate need for testing which would be a great way to help

technoplato commented 5 years ago

10 4 @mikehardy Thanks for letting me know. Will be paying close attention in the mean time.

During the period with no rnf v6 support for notifications, is there a way you would recommend getting Firebase notifications to work?

mikehardy commented 5 years ago

v5 :man_shrugging: - it's what I'm doing (and I'm supporting / patching / releasing v5.x so we can use up to date react-native and firebase sdks, so it's not dead-end at least)

technoplato commented 5 years ago

Really stupid question here, apologies in advance: I can't use v5 and v6 simultaneously, can I?

technoplato commented 5 years ago

I was having issues with project portability, so took the time to nuke everything <v5 and came over to v6 land. Been quite happily living here, so don't want to trod back if I don't have to.

mikehardy commented 5 years ago

v5 and v6 do not work together in any way, sorry

technoplato commented 5 years ago

Hey @mikehardy, just recently came across this Project board: https://github.com/invertase/react-native-firebase/projects/5

Is that something you guys keep up to date?

mikehardy commented 5 years ago

I believe it's up to date but I don't work directly with the invertase crew on moving features forward - they use the board to coordinate that I believe. I'm more just combing the issues list for triage and keeping v5 running so they have more space to work through that board :-)

technoplato commented 5 years ago

Brilliant, thanks for clarifying!

waqas19921 commented 5 years ago

@technoplato here https://github.com/invertase/react-native-firebase/pull/2529 is the notifications pull request i guess its merged somewhere

technoplato commented 5 years ago

@waqas19921 good find. It wasn’t merged though it was closed.

@Salakar can you say why this was closed? Will it be merged soon?

Ehesp commented 5 years ago

@technoplato We had to prioritise the Firebase modules as we're releasing v6 soon. A notifications migration for v5 -> v6 will be completed in the next couple of weeks.

technoplato commented 5 years ago

Thanks for letting us know @Ehesp

If there's anything we can do to help, please let us know.

technoplato commented 5 years ago

Info confirming from the 6.0 release post:

FROM: Announcing: React Native Firebase version 6.0.0 | Invertase

Where is the Notifications library?

We're almost complete migrating the notifications package, please bear with us. As each module is now its own npm package we did not want to hold up the rest of the React Native Firebase modules any longer than necessary because of the notifcations package, we'll publish the notifications package in the next 2-3 weeks

mikehardy commented 5 years ago

I just changed the title and I'll use this to update with status as/when available, and it will serve as a place to point people that ask (via other issues, or Discord or whatever) since it is a popular request

lironsher commented 5 years ago

Hi Is there anyway to use version 5 notifications with version 6?

mikehardy commented 5 years ago

@lironsher no, the v5 and v6 versions don't mix. I updated the main issue text above.

chubecode commented 5 years ago

Hi Team. It's still processing right? I still waiting.. Hope can see it early.

lironsher commented 5 years ago

@mikehardy Thanks, Do we have an ETA for version 6 notifications?

Ehesp commented 5 years ago

Please see above comments; no, but soon.

mikehardy commented 5 years ago

Not directly related to notifications status, but for everyone waiting - if you saw the mass-closing of issues yesterday/today (via merged changes and a 6.0.1 release) you'll realize that the v6 release is a process and fixing the most critical reported bugs in it takes the same time otherwise available for notifications.

For me that's a powerful indicator of forward progress. I'm sure notifications will be along soon, while v6 in general also stabilizes.

metasanjaya commented 5 years ago

Waiting here...

rtman commented 5 years ago

@metasanjaya

Mate, plenty of people are waiting patiently for this. No need to be so obnoxious about it. They are clearly working on it.

younes200 commented 5 years ago

We understand, but we need an ETA for this otherwise a how-to documentation to mix react-native-firebase v5 Notification ! Thank you.

jeremybarbet commented 5 years ago

Both your questions have been answered above:

ETA: "Please see above comments; no, but soon." Mix: "no, the v5 and v6 versions don't mix."

And stop being so impatient for something free and open-source, they are already doing a great job, not need to ask them every day when it's gonna be released.

younes200 commented 5 years ago

Well tell that to your impatient users... I understand the free/open-source argument but what I don't understand shipping a new release without a critical feature of the previous one...

compojoom commented 5 years ago

@younes200 - you don't have to use v6. You can use v5 with RN .60 and .61 The difference is v5 is one huge package, v6 is splitted in several smaller packages. With v6 users will be able to only pull in the packages and parts of firebase they actually use. E.g. if you only use crashlytics and no notifications you can use v6. With v5 if you were using just crashlytics you would still pull in all other firebase packages, which would drive your bundle size up.

I want to underline again - v5 works with the latest version of RN.

I personally would love to use v6 because of the improvements to the stack trace in crashlytics, but can't because notifications are not ready.... So, we stay on version 5 and wait for notifications to catch up.

appli-intramuros commented 5 years ago

@compojoom Amen !

mikehardy commented 5 years ago

Confusing needs and wants is a modern era trap. Others have explained you may stay on V5.

Consider this though

As for understanding the why, consider this - notifications is not actually a firebase feature set. There is no API surface area in the underlying SDKs that has to do with notifications. Messaging yes, notifications, no. So if you imagine that you were going to be referenced (in the keynote no less) at the global conference for your technology, and wanted to get your new version out prior, would you focus on the actual SDK of the product you were involved in, or a part that was actually just on the side? So pragmatism wins. Imagine further if it was really important to do so because open source projects don't generate much money, so you really need (not want) to take advantage of the opportunity. Perhaps the background information will promote empathy.

Constructive actions to take:

1- assist new and existing users with support so that the primary authors have time to finish the thing you want: https://github.com/invertase/react-native-firebase/issues?utf8=✓&q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

2- PR bugfixes to keep v5 alive, or move v6 along https://github.com/invertase/react-native-firebase/pulls?utf8=✓&q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

3- There is even an outstanding critical issue specifically with the V5 tree you need that would be great to solve: https://github.com/invertase/react-native-firebase/pull/2473#issuecomment-541064233 - until that's resolved I actually can't do a clean release on v5.x.x which is a real problem

4- Here's an alternative thought, perhaps we could all then switch off react-native-firebase's implementation of local notifications to another package then? That might actually be the best thing for react-native-firebase as I mentioned above it is actually not in the firebase SDK API surface area

Behold the state of the other options:

https://github.com/wix/react-native-notifications

https://github.com/wumke/react-native-local-notifications

You may integrate those in your app and I'm certain the users there would appreciate PRs to fix anything you find wrong

So as far as I know, that's all the relevant options for constructive participation, other than patience.

kneza23 commented 5 years ago

Not sure about decision of removing notification functionality from react-native-firebase as it really simplifies the whole process of taking care and displaying the notification without need of additional dependency.

For me personally it is amazing modular feature that i can just plug in along with other functionalities that react-native-firebase has.

mikehardy commented 5 years ago

@kneza23 I agree with you from a library consumer standpoint - but I hadn't actually looked at the open source libraries that also attempt it, I was actually shocked / saddened to see their state. Which is another way of saying that it is clearly a very hard surface area to cover. And the user support load here on notifications is incredible for that reason as well ("I can't get my BigPicture to work", "getInitialNotifiction should be dequeue when you fetch it", "my action buttons don't work", "how to get a notification in the background" and on and on :-) - I basically refuse to support it myself for that reason, the fatigue is real.

That's not a constructive comment per se - nothing actionable here - but it might deepen understanding of what it means to attempt to cover the scope of local notifications. It's kind of a nightmare as a developer

kneza23 commented 5 years ago

@mikehardy i understand you. Maybe if you can switch it of to other package and give more control/responsibility to the community but still keep it pluggable to the react-native-firebase. That would be amazing but it would also raise some compatibility problems (keeping up with versions and updates) in the future i presume.

kneza23 commented 5 years ago

@mikehardy but make no mistake, react-native-firebase notification feature is still miles ahead of other options.

technoplato commented 5 years ago

@kneza23 theres nothing stopping us from creating a RNF pluggable notifications package.

Would you be willing to work with me and perhaps others to make something like that happen?

Although, I’d imagine that Notifications v6 is coming soon enough and that would be a lot of duplicated work.

mikehardy commented 5 years ago

@kneza23 Switching to another notifications package as a mass and actually offering work capacity (fixing open issues, getting it up to a high level) might actually be the best option - for react-native-firebase as well as the notifications package is an anchor here - lot of pain, no gain.

I also believe v6 notifications is close but the expected outcome there is a raw port of v5 notifications with just the structural changes necessary for it to run in v6 - in other words it will still have the built-in problems of not being a firebase core API and having a massive (unwanted) support burden here from maintainers that frankly aren't motivated for it (not a criticism: I would not be motivated for a non-core API either - I shed those as soon as possible as a maintainer)

If I had to choose I'd go with https://github.com/wix/react-native-notifications - do a quick feature-by-feature comparison on raw notification features, post that somewhere and ask there for interest on PR'ing the rest. I'm not sure there really needs to be much specific work to make it "pluggable" with react-native-firebase, other than documenting that if you use RNFB, you don't need the push-notification features of the wix package

Ashoat commented 5 years ago

Just want to chime in with a huge thank you to the maintainers of this package - both @mikehardy who has been helping out with the 5.x branch and the Invertase folks that maintain the whole suite. I’ve tried a lot of the aforementioned alternative packages in the past and they were nowhere close to react-native-firebase in terms of documentation, productionization, or support.

It would be extremely unfortunate for me and many others if the notif support was dropped from this package. I would certainly sooner fork this package than go back to any of the other options.

nachourpi commented 5 years ago

Hello everyone, well I have read everything I do understand the arguments of @mikehardy but I'm not quite sure of the limitations of this. I have recently updated all the packages of my project, actually I started it from scratch with RN 0.61 and everything else updated. The thing is that I updated react-native-firebase to 6.0.1 and just found out that there's no firebase-notification support yet...

However, Im not quite sure what are the recommendation. I just want my phone to open a native notifications popup even if my app is closed when my server send its (its currently using FCM to do so). Is this still posible with @react-native-firebase/messaging module? At this point Im kind of confuse, is @react-native-firebase/messaging only used for data messages ? I mean for getting my app and server communicated in real time only when my app is in foreground?

Are you suggesting that I get a FCM push data on background and when I detect it I open a local push message with other library?

Thanks and please forgive me for my pity english !

mikehardy commented 5 years ago

@nachourpi I'm living in a country that does not speak my mother tongue, no worries on the english, it's great.

react-native-firebase messaging is for messages from the cloud to devices. That's is scope. sometimes cloud messages invoke local code on the device to pop notifications, it is possible to do that with a combined data+notification message, but most find it inflexible (more on that below)

Notifications is your app (or code brought in by your app) popping notifications up to the user.

They are related by separate.

RNFBv6 does not have notifications yet, but messaging is in and working I believe

If you are already on v6 then I think you will need to integrate one of the alternative packages mentioned above, or go to v5, or wait.

I believe the best implementation pattern for cloud messages is to completely separate them from notifications functionality - in that you only send silent-push from the cloud then in your handler you pop local notifications as a response in your code.

If you use that style then what package you use to do the local notifications is less important.

Hopefully this helps?

Ehesp commented 5 years ago

Hey all,

Firstly we really appreciate the passion going on in here, it's awesome to see such hunger for something we're developing. Let me just give an update on where we are at, and what our current thinking is:

This library is one of the largest externally maintained libraries for React Native, from a downloads/stats and size point of view, and we've kept it actively maintained for almost 5 years - when others would have been abandoned by now. Documentation alone is a huge effort to keep up to date - the v6 documentation site has hundreds of pages of docs. Not only do we have to work on Notifications, we also have to support all of the other Firebase services - as you can imagine that's no small feat.

We are a small company maintaining this and we're not (and don't want to be) VC funded, and; like all companies we also have financial costs that need satisfying - so we can't be working on this full time all the time (even though we pretty much have for the last year) - its not sustainable as a business.

With these points in mind, we have decided moving forwards we're going to move the Notifications library of React Native Firebase into its own library. Why are we doing this?

The other topic we've been discussing, as a business, is the sustainability of OSS. We love OSS and we invest a huge chunk of our time into OSS, but free software doesn't pay the bills. We're a small company and need to ensure we stay afloat - we've also started working on private/internal projects to ensure this happens but this cuts into the time we can spend on OSS.

To ensure that a new Notifications library is well supported going forwards, we have recently come to the decision to make the new Notifications package a paid/licensed package for a very small fee, however; it will be free to use in development, free to use for React Native Firebase core contributors, free to use for non-profits, free to use for early testers/alpha testers and free to use for fully OSS apps (e.g. https://github.com/devhubapp/devhub).

This decision wasn't taken lightly and we've had many long discussions about it, but the goal here wasn't to make a quick buck but instead provide the financial means to keep the project well maintained and supported for the foreseeable future. If your thoughts on this decision are negative, we hope you understand however that there are free alternatives as listed above & v5 notifications is still available to use.

This new library is not aimed at being port of v5 notifications; everything has been re-written from the ground up to be well tested, cover most of the available APIs and be extremely well documented with step by steps guides & illustrations on all the notification features/APIs. As of right now, we're making good progress. Android is 75% complete (our primary focus) and the documentation is coming along well too. We're not in a position to give a date anymore, because honestly we have no idea given the scale of the project now. Guesstimates would be mid-November for an alpha release.

If you're interested in Alpha testing, please fill out this form and we'll be in touch once we're ready for testers: https://forms.gle/6huxd2ffgT4TBeXo9

Salakar commented 5 years ago

To follow up on the above; we'd 100% be open to accept community led contributions for any or all of the following as stop-gap solutions:

We're open to discussing other strategies on how to deal with this in the short term.

nachourpi commented 5 years ago

@Ehesp I would definitely pay for that notification library! Right now I have a client with a non-working app that has to be fixed ASAP, and can't wait till November so I guess I will downgrade to RNFBv5 as suggeted by @mikehardy .

Thanks

bitlab-code commented 5 years ago

Hey all,

Firstly we really appreciate the passion going on in here, it's awesome to see such hunger for something we're developing. Let me just give you guys an update on where we are at, and what our thinking is [...]

@Ehesp, @Salakar nothing to add, I fully agree with your decision, it makes sense and it's honest.

Like other thousands of developers and small companies, we will never stop thanking you for your work while waited quietly (without unnecessary post) for what was announced.

So the only flaw is the lack of initial clarity.

Anyway, thank you for your commitment and thank you for the update. I believe that many others like me look forward to this latest announcement, willing to pay if it's acceptable

alittletf commented 5 years ago

@Ehesp @Salakar @mikehardy Keep up the good work guys! idk where I would be with out your libraries. On the charging for notifications, I am totally cool with that too. I'd happily pay for something I need vs see the project slowly die

gamingumar commented 5 years ago

We totally support your decision and would definitely pay for it.

LukePenkava commented 5 years ago

Please excuse my ignorance, so with v6 i should be able to have remote notifications working with cloud messaging ( as it seems to work ), but local notifications will be separate package sometime later this year? So if i dont need local notifications and all my notifications are coming from firebase server i am good to use v6? Sorry, i just want to clarify, so i know if i should downgrade or not.

Btw i think that releasing paid version is totaly fine, i honestly dont understand the whole free open source idea of the react native modules. I mean its great and all, but i am coming from game development and Unity3D, where every community plugin which is any decent is always paid. That naturally allows the developer to support the tool much better. If i need to pay $50 or something like that for RNF license and get even better support and product i am all for it.

mikehardy commented 5 years ago

@LukePenkava if you don't touch firebase.notifications() I believe v6 is fine, firebase.messaging() exists for v6

firofame commented 5 years ago

@LukePenkava I totally understand that $50 might not be much in the West but it's not the case around the globe.

React native is widely used by students, individuals, startups & smaller organization to cut cost on maintaining two different teams for iOS & Android. Every penny counts for the little guy.

I do agree that we need more well maintained plugins and It's fine if some of them are paid. We need more of them too.

Let's acknowledge and thank all the FOSS projects that subsidies software development for all of us.

LukePenkava commented 5 years ago

@firofame I realy have no horse in this. I am just regular dev and whether RNF stays free or is paid is up to them. I am just saying that this "everything for free" mentality has no equivalent in indie game development for example. I am not judging whether its good or bad, just stating it. I just find it fascinating how much work many people put into these modules whether its firebase or anyting else without any compensation for their time.

I of course also personally prefer that it is free :) but i would be totaly ok if it was paid. Honestly $50 is not that much, think how much time it saves you to use something like RNF if you would have to do both solutions yourself for iOS and Android and compare it to hourly rate of dev. Is $50 realy that much? Btw i am from eastern Europe, not form US.

Thats just my opinion and again, its up to the devs of RNF to make that decision and i understand its preferable to have these things for free, since it makes it more accessible to younger people who have no money or to people who actualy cant afford those $50 ( or whatever would be the cost ).

Ehesp commented 5 years ago

I am just regular dev and whether RNF stays free or is paid is up to them.

React Native Firebase will always be free & be FOSS (fully open source software). A paid library is only for notifications.

@firofame we understand your concerns about the pricing. As mentioned above, our decision isn't about making profit, it's about long-term sustainability. We want to ensure individuals and small startups (like ourselves) no matter where they're from can use the module without it being a costly overhead and we've been planning pricing with this is mind.

We have some awesome plans for the notifications library and are super excited to get it released, it isn't going to be a port of v5 notifications that's for sure.