<@&844001800214020128> I would definitely recommen...
# off-topic
k
@User I would definitely recommend when updating your libraries which introduces a breaking change to provide a migration process. for example supabase-flutter in the client it had a function which was returning
Future<bool> hasAccessToken()
and after I updated the library, basically there was no where I could find that it had been changed. just a tip for the future tho 🙂 especially with supabase 0.1.0 I see it has alot of breaking changes but nowhere in the changelog it mentioned the breaking changes.
Copy code
[0.1.0]
chore: update supabase to v0.1.0
feat: using hive to persist session by default
this is definitely a bad developer experience and I hope this changes in the future. thanks 🙂
h
@User I would definitely recommend when updating your libraries which introduces a breaking change to provide a migration process. for example supabase-flutter in the client it had a function which was returning
Future<bool> hasAccessToken()
and after I updated the library, basically there was no where I could find that it had been changed. just a tip for the future tho 🙂 especially with supabase 0.1.0 I see it has alot of breaking changes but nowhere in the changelog it mentioned the breaking changes.
Copy code
[0.1.0]
chore: update supabase to v0.1.0
feat: using hive to persist session by default
this is definitely a bad developer experience and I hope this changes in the future. thanks 🙂
@User @User FYI
btw, flutter libs are maintained by the community 😅 (I myself, contributed to these projects) right now only javascript libraries are supported officially by Supabase team
t
Ah, right. Sorry for that @User . Thanks for the heads up! It's on me. Will do in the future.
b
sorry about that! @User do you need help on migrating?
k
All good with the migration for me as i could scan ur changes and see what changed but its abit troublesome to do this. Just a guide on migration in the future will be really great. Thanks tho for ur contribution and improvements on the Library :)
@User just updated to 0.1.0, first thing I noticed I needed to
await
on initializing supabase.. which is a breaking change. second biggest thing which is by far gonna cause alot of trouble is that, users are logged out now. how can I prevent this? I already released my app migrating them to supabase and i'm using email login, now if I push a new update, everyone will be logged out and this a big chorn factor.. could you please, update the library to have HIVE as an alterantive to older versions or provide us the old localStorage implementation as an option to choose...
b
you can create a class that extends
LocalStorage
and implement your custom local storage solution
we used to use shared_preferences, and you can create a custom local storage implementation for it
and it should work
we migrated to hive cuz it's more secure, but you can still use shared_preferences
k
But you realize that this not only breaking change but rather breaking clients.
You can't simply update an auth library without having a fallback to keep logged in users still logged in.
b
the library was in beta, breaking changes were likely to happen. It's not like it was stable (1.0.0)
k
Also, I don't understand the use of hive to store tokens in shared pref.
Beta doesn't mean, the api isn't stable.
b
yes it does. we upgraded from 0.0.8 to 0.1.0 because this is a big breaking change
if it was a normal change, we would publish 0.0.9
k
Yes, I noticed that, but you aren't only breaking dev library, you are also breaking their user usage of the library.
I believe, whenever such thing happens, serious thoughts have to flow through to find out what's best way, not only as what we dev see, but also about the devs we providing the library to and their customers.
Don't get me wrong here, I know I sound passive, but I'm trying to get you to figure out that there are definitely some apps who uses supabase in prod already and having such huge breaking change is just frustrating.
b
indeed
In this PR, I show how to create a shared preferences instance of local storage, if that helps:
k
I'll have to dig in to previous version to figure the keys to these values.
b
like
supabasePersistSessionKey
?
k
Also, outa of curiosity. Why using secure storage anyway? Judging by the shared pref in android is sandboxed and only can be accessed by other apps if the phone is rooted. Same applies to apple, its almost impossible to get that either.
What was idea behind it?
b
mobile is not the only platform targeted by the lib
yes, shared preferences are secure in android
but not on Windows and linux
and not on embeeded too
hive still exposes the files, but they are stored in binary text (iirc), making it harder to access the info
and you can encrypt it with a custom key
k
Makes sense but as a library we should expose your new storage implementation and let others hook in their choice of secure storage. Having said that, sharedpref should be the default one so the library stays unware of what others want to do with it.
b
why should a non-secure solution be the default one? If devs want to use it, they can create an extension of
LocalStorage
with it, it's not hard at all
either way, we'll provide a migration guide to all breaking changes
k
I know, but a library should not be decoupled with so much external libraries and should provide devs the way to customize things without having dependencies on other libraries that some apps never include. Someone has to also maintain updating supabase Everytime hive have new version that deprecated something or removed something or other apps uses higher version that supabase included version. Dependencies can be really tough topic 😅 Thanks 👍
b
> library should not be decoupled with so much external libraries I agree with this one! tho, about hive, if not used, it won't increase your app size... flutter apps are tree shaken
k
Yeeep, until u have different version from that lib 😅.
b
wdym?
k
Lets say, you have Hive 1.0.0 in supabase My app has 1.1.0 hive. 1.1.0 has some api changes. I can't update until supabase is updated.
b
tho it's open source.. you can fork and change it to the required version 🙂
also, compared to firebase, supabase_flutter is so damn light. Firebase takes up to 10MB of your app, when supabase doesn't take even half of it
k
Yeah, now, everything is essy, wait until Supabase becomes firebase size..
I meant in project popularity not mb 😅
b
ooh
k
There is other way to it tho, apps don't want to update to 1.1.0 of hive, Supabase does, now Supabase forces clients to do huge refactoring so their app can function.
I'm sorry, I sound so demanding, its just my job to worry about these stuff and ensure smooth dev experience 🙈
b
ooh yeah
no worries mate
we'll take more care next time 🙂
t
Thanks @User for the feedback. We will make sure to take better care in the future. These feedbacks are amazing. Please keep them coming if you notice anything in the future again!