Commit list accounts state after difference in removed accounts is determined #82
No reviewers
Labels
No labels
a11y
Bug
Bug fix
Critical Priority
Documentation
Feature
Feature request
Held for next release cycle
High Priority
Low Priority
Medium Priority
Minor change
Translation/Locale
WIP
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma-fe#82
Loading…
Reference in a new issue
No description provided.
Delete branch ":commit-list-accounts-after-delete"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently updated account list in editing a timeline list is being committed to the state before account difference is calculated and acted upon in API DELETE call, which results in no difference between comitted and new lists and accounts being impossible to delete from the list as consequence. Also POST call is executed always with full list of accounts, which is not necessary and both calls are performed regardless of presence of changes. This PR moves calucaltion of difference before the commit, and makes POST/DELETE API calls predicated on non-empty difference.
Added guards for both POST and DELETE API calls so those will only be executed if there was actually some accounts added or removed. Also had to make sure that store getter would return a copy of internal list, so it won't get modified outside the store, otherwise
added
would always be empty.one nitpick
seriously though pls do change that bio i don't wanna actually act on any warnings - just... y'know don't make me say it again
@ -77,3 +81,3 @@
},
findListAccounts: state => id => {
return state.allListsObject[id].accountIds
return state.allListsObject[id].accountIds.slice()
the preferred way to duplicate an array is via the
...
syntaxreturn [...state.allListsObject[id].accountIds]
As far as performance goes, ths is less optimal option. But if you want to prioritize readability, sure.
the difference in performance would only actually be relevent if we were dealing with (tens of) thousands of elements, which we're not
0d1daa948d
tofebf0d0c77
Sure thing. Done.