Data: Implement preferences persistence using user settings #15800
Conversation
| storage: { | ||
| getItem: function() { | ||
| return ( | ||
| window.getUserSetting( 'dataState' ) || |
There was a problem hiding this comment.
How complex it would be to transform this to a package. To be clear, I think the current proposal is good enough, just wondering if we should take this opportunity to packagify this.
There was a problem hiding this comment.
Just saw the size limitations, it's unfortunate. What's the alternative you're thinking of? an endpoint?
There was a problem hiding this comment.
Yeah, I like how nice this solution is. I'd give it a try and see how it scales :)
Try to disable all blocks using Block Manager and check again 😅 I know that I'm not helping here but this might be an actual issue. We still could try to go with this proposal as it solves the problem for the majority of cases. |
| ); | ||
| }, | ||
| setItem: function( key, value ) { | ||
| window.setUserSetting( 'dataState', value ); |
There was a problem hiding this comment.
The source code of the method:
// Both name and value must be only ASCII letters, numbers or underscore
// and the shorter, the better (cookies can store maximum 4KB). Not suitable to store text.
|
I should have been clearer in my original comment: I have little faith that this implementation is viable. Cookie limitations are likely a blocker. It's presented here both as (a) a showcase at an attempt to reuse existing functionality and (b) to solicit suggestions which would allow for cookies to be used, considering the noted limitations. I expect it would probably be closed and we move to an alternative implementation, likely using user meta, server-side inline scripts to "upsert" the persisted value into localStorage, and continue to use the localStorage mechanism, syncing from the client on change using user endpoint meta fields (related comment: #15105 (comment)). |
|
Hi @aduth, It seems there is a decision already taken not to follow this approach. But as another point doesn't this approach suffers from the same problems as the local storage? E.g.: if the user has some extension than cleans the cookies all the time will not the preference be ignored? Settings will also not be synchronized across devices right? |
|
@jorgefilipecosta On the surface, it would appear that it would, but the cookie is used more as a transportation mechanism. Both the server and the client are aware of the cookie, and the server will persist changes to the database. If the user loses the cookie for whatever reason (new browser, clear storage), the server will also restore it. It works quite well, but the main blocker are the storage limitations on cookies, which are much smaller than we can probably tolerate. |
|
Closing as non-viable. Discussion for the original issue should continue in #15105. |
Closes #15105
This pull request seeks to explore a (likely non-viable) approach for preferences persistence, leveraging the user settings cookie, existing
utilsscript methods for operating on this cookie, and substitute storage implementation for the data persistence plugin.Problems:
setUserSettingsexplicitly forbids (and removes) non-ASCII characters from values, so storing a stringified JSON blob is not directly feasible (source)For this reason, it may not be advisable to consider the cookie for storage, though there is an appeal in trying to reuse an existing feature targeted at an identical goal (client-side UI settings).
Alternative considerations will continue to be proposed in and linking to #14512.