Open CertainPerformance opened 4 years ago
I believe the code comes from a time when there were storage limits per key in the LocalStorage implementations, if there weren't even other restrictions or storage patterns at the time.
Either way, the change seems perfectly reasonable, but the code hasn't been maintained in years and if new releases will ever be built is questionable.
If you want to work on it, you're welcome to do so, but hopefully you won't rely on support from original maintainers, because we haven't worked on this in a long time and I personally refuse to work on anything related to that cancerous, hateful platform and company.
If you do the work and send a pull request I don't mind having a look at it, but I'm not 100% sure I still have the access rights to update the chrome extension on the store. Nor that it still corresponds to their criteria.
On Wed, 29 Apr 2020 at 09:33, Oliver Salzburg notifications@github.com wrote:
I believe the code comes from a time when there were storage limits per key in the LocalStorage implementations, if there weren't even other restrictions or storage patterns at the time.
Either way, the change seems perfectly reasonable, but the code hasn't been maintained in years and if new releases will ever be built is questionable.
If you want to work on it, you're welcome to do so, but hopefully you won't rely on support from original maintainers, because we haven't worked on this in a long time and I personally refuse to work on anything related to that cancerous, hateful platform and company.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Benjol/SE-AutoReviewComments/issues/175#issuecomment-621037351, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACE6AWTCU7NGQWJUU6JEWLRO7J4HANCNFSM4MTN2QLQ .
I pretty frequently look through SE sites' Local Storage when debugging my own scripts. Every time I do, I'm faced with screens like this:
AutoReviewComments' keys are everywhere - there are about 60 of them for me (depends on how many auto-comments one has saved). It's not only annoying, it's also a pretty inelegant storage pattern. A better choice would be to use a single property instead. For example, rather than
AutoReviewComments-commentcount
,AutoReviewComments-WelcomeMessage
,AutoReviewComments-desc-6
,AutoReviewComments-name-6
,AutoReviewComments-LastUpdateCheckDay
, a single object could be used instead:JSON.stringify
can be used to save such an object in storage, andJSON.parse
can turn the JSON string back into an object:I would love if I could make a pull request to change AutoReviewComments' storage to the above structure. Would this be an acceptable change for me to work on?
This would still be completely backwards-compatible: the script can check to see if the individual AutoReviewComments keys exist, and if they do, they could be extracted to construct the new settings object. The modifications would still be able to read settings in either the individual format or consolidated format, but would only save settings to a single key.