Fix setting persistence to local browser storage #469

Merged

Oneric merged 1 commit from Oneric/akkoma-fe:fix-settings-local-persistence into develop

2025-12-19 19:20:14 +00:00

Oneric commented

2025-12-19 19:11:00 +00:00

Owner

Fixes regression in f2c55423fd.
Ideally, this would only set state for what was actually changed
rather than rewriting the entire storage each time, which would also
have avoided this issue.

The fix is somehwat hacky not working with an empty path list or
parsed/internal fields not at the top-level of a path, but in practice
this seems to be always called with well bheaving paths. Should this ever
become an issue, this should migrating to the overall saner updating
approach described in the preceding paragraph.

Note: the cloneDeep call was originally added in
a97c07bfdf as part of
https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1385
Though it is not clear why setState would mangle its data argument
as it supposedly does to necessitate this copying.

Fixes regression in f2c55423fd02ed93c8483001ef7cee6eed2b56d4. Ideally, this would only set state for what was actually changed rather than rewriting the entire storage each time, which would also have avoided this issue. The fix is somehwat hacky not working with an empty path list or parsed/internal fields not at the top-level of a path, but in practice this seems to be always called with well bheaving paths. Should this ever become an issue, this should migrating to the overall saner updating approach described in the preceding paragraph. Note: the cloneDeep call was originally added in a97c07bfdfd8b69d59fec619d269cf14d65d8e0c as part of https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1385 Though it is not clear why setState would mangle its data argument as it supposedly does to necessitate this copying.

Oneric added 1 commit

2025-12-19 19:11:01 +00:00

Fix setting persistence to local browser storage d83fd8b1cd

Fixes regression in f2c55423fd.
Ideally, this would only set state for what was actually changed
rather than rewriting the entire storage each time, which would also
have avoided this issue.

The fix is somehwat hacky not working with an empty path list or
parsed/internal fields not at the top-level of a path, but in practice
this seems to be always called with well bheaving paths. Should this ever
become an issue, this should migrating to the overall saner updating
approach described in the preceding paragraph.

Note: the cloneDeep call was originally added in
a97c07bfdf as part of
https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1385
Though it is not clear why setState would mangle its data argument
as it supposedly does to necessitate this copying.