Hi @gdurandrexel, please provide a complete minimal reproducible code sample so that we can properly investigate this.

Please also provide the version of shared_preferences & shared_preferences_web you're using.

Thank you

I use version 2.2.2.

As for a reproducer:

• create a web project,
• put the code above in main(),
• create a plain text key in the local storage from Chrome
• launch

The problem is obvious in the code of packages/shared_preferences_web/shared_preferences_web.dart 262:37: json.decode() is called on the retrieved value, which fails because it is not a json value

Is there a reason you are not passing an allowList as part of your options? Not doing so means you are explicitly asking for SharedPreferencesWithCache to cache every value. Dropping some values silently in that scenario is actually not unambiguously correct.

That said, we do filter unsupported types on iOS/macOS, so silent filtering would be consistent, and from discussion in flutter/packages#5813 I think there's consensus that it's the better option. Anyone interested in completing flutter/packages#5813 is welcome to contribute a new PR.

Using allowList is cumbersome: I have to track all the keys I use with no real benefit for me.
The prefix system used by the previous version was much less effort. I would prefer to have that in-lieu or in addition to allowList.

A more general thought: if the package uses a shared storage and does not support all the data types of the storage, it should probably handle gracefully the unsupported data types by default. Asking the user to setup this mechanism explicitly with allowList or prefix or try/catch does not seem right.

Also, if for whatever reason a value is not in the expected format, then the whole initialisation fails. In my case I prefer having some of the values (which should be all the ones I created with this package) than none at all.

@gdurandrexel you found a workaround?

In one project I just used SharedPreferences instead of SecureStorage (which was creating a plain text entry) to avoid having plain text entries.
In another I used allowedList. This is what should be used for now as it is the safest solution.

To go futher with this, the meaning of a null allowList should be clearly defined (if allowed at all):

• option 1: read all the values in the storage. I don't understand why this would be desirable. In this case the package should make an effort to read all the values, whatever their format.
• option 2: read all the values managed by SharedPreferences. In this case, store the values with a discriminant allowing to know what values are managed by SharedPreferences (using a prefix for instance), and read only these values. Personnally I would be OK with reading all readable values whatever their source, but that should be documented as it is not obvious.

In any case, the initialization must not fail.

• option 2: read all the values managed by SharedPreferences. In this case, store the values with a discriminant allowing to know what values are managed by SharedPreferences (using a prefix for instance), and read only these values.

The reason the new APIs don't do that is that there was significant feedback over the years with the old API that people wanted to be able to access values that were not stored by the plugin, especially in add-to-app or migration-from-non-Flutter use cases. The lack of automatic prefixing is an intentional change.

In any case, the initialization must not fail.

As I said in my earlier comment:

Anyone interested in completing flutter/packages#5813 is welcome to contribute a new PR.

@stuartmorgan I plan to create a PR in the near future. To do this, I need to figure out how to write integration tests.

@stuartmorgan I did it. If you don't mind, could you take a look, please?

flutter/packages#8211