search

DmitrySharabin / mavo-firebase-firestore

Firebase backend plugin for Mavo. Store and sync app data in milliseconds. Store and serve files at Google scale. Authenticate users simply and securely. All the Google Firebase powers are at your fingertips.
https://plugins.mavo.io/plugin/firebase-firestore
MIT License
6 stars 0 forks source link

A way to handle (enable/disable) Firebase features #8

Closed DmitrySharabin closed 4 years ago

DmitrySharabin commented 4 years ago

@leaverou @karger Lea, David, do you mind giving me a piece of advice?

Are there proper ways to let users customize a Mavo plugin behavior?

For now, my plugin supports these three features: auth, storage, and real-time data that are disabled by default. The ways a Mavo app author can switch them on are different. The first two are enabled with the help of the corresponding values for the mv-firebase attribute. The latter—via the boolean mv-firebase-realtime attribute. Both these attributes go to the Mavo root element.

Now I want to add a new feature to the plugin—offline persistence, which Firebase supports out of the box. I have a dilemma: whether I should add the new boolean mv-firebase-offline attribute or the new offline value for the existing mv-firebase attribute? Or should I support both ways?

Should I refactor the code to provide the plugin users a more consistent way of enabling/disabling its features? E.g., what if I leave only the mv-firebase attribute that accepts all four values: mv-firebase="auth storage realtime offline"?

I'll be grateful for any of your thoughts. Thanks in advance!

DmitrySharabin commented 4 years ago

I decided to remove the mv-firebase-realtime attribute and let Mavo authors enable Firebase features more consistently via the mv-firebase attribute.

The built-in into Firebase offline persistence doesn't really make much sense in Mavo apps. So, I decided not to include it in the plugin. If Mavo authors need the offline mode in their apps, they can use the existing Offline plugin.

karger commented 4 years ago

I think the mv-firebase attribute for enabling features makes sense wen these features are boolean. For non-booleans, e.g. a feature that needs some sort of argument, using separate attributes would be cleaner.

I'm less clear on using the separate mv-offline plugin to provide functionality that firebase already provides natively. As one example, the firebase version is likely to keep working longer if people stop maintaining the offline plugin. Is there any reason not to just have firebase offline mode enabled at all times? What benefit would there be to turning it off?

DmitrySharabin commented 4 years ago

I think the mv-firebase attribute for enabling features makes sense when these features are boolean. For non-booleans, e.g. a feature that needs some sort of argument, using separate attributes would be cleaner.

Got it. Thank you.

Is there any reason not to just have firebase offline mode enabled at all times? What benefit would there be to turning it off?

I believe there are no benefits.

OK, I'll enable offline persistence, and will try to make the plugin behavior as seamless as I can so end-users won't notice any difference whether they are online or not. By that, I mean that when we are offline and try to save changes, the saving indicator is being shown and is not being hidden after a while. And there might be an impression that an app is hung.