Page MenuHomePhabricator

[web] Display user tags
ClosedPublic

Authored by tomek on Jun 21 2022, 5:48 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 9, 7:59 AM
Unknown Object (File)
Oct 14 2024, 12:46 AM
Unknown Object (File)
Oct 14 2024, 12:46 AM
Unknown Object (File)
Oct 14 2024, 12:46 AM
Unknown Object (File)
Oct 14 2024, 12:46 AM
Unknown Object (File)
Oct 14 2024, 12:46 AM
Unknown Object (File)
Oct 14 2024, 12:46 AM
Unknown Object (File)
Oct 14 2024, 12:42 AM

Details

Summary

Show a list of users that are about to be added. Clicking an x button next to their name removes them from the list.

pending_users.png (1×1 px, 128 KB)

Depends on D4308

Test Plan

Add a couple of users and then remove a couple of them. Every time a name is clicked on the list a tag is added. Every time a tag is closed, the name is added back to the list.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Early exit when there are no users selected

tomek requested review of this revision.Jun 21 2022, 5:59 AM

Looks good, two questions inline to be addressed before landing

web/settings/relationship/add-users-list.react.js
117–123

Could we simplify this and replace with:

return pendingUsers.filter(({id}) => id !== userID)

?

I'm guessing the reason we're checking if filteredPendingUsers is the same length as pendingUsers is to avoid setting pendingUsersToAdd to a new identical object if nothing has changed...

But, can't we assume that deselectUser will result in a different pendingUsersToAdd? If there is some edge case where that isn't true, is the cost of creating the "same" object with a different reference a big deal?

137

Might be missing something here, but shouldn't we memoize this with React.useCallback(...)?

Maybe deselectUser should accept a userInfo instead of userID if that's simpler?

This revision is now accepted and ready to land.Jun 21 2022, 12:02 PM

As an aside, I think some of the state logic could be extracted into hooks?

In D4309#121639, @atul wrote:

As an aside, I think some of the state logic could be extracted into hooks?

Giving names to the hooks which are used might indeed improve the readability. On the other hand, moving the hooks to other place would make the code more scattered, which could make it harder to understand. Will explore it a bit.

web/settings/relationship/add-users-list.react.js
117–123

Ok, we can do that - it was probably over-engineered.

137

This is enclosed by a memo, so memoizing it doesn't make a lot of difference.

Maybe deselectUser should accept a userInfo instead of userID if that's simpler?

I don't see why it would be simpler. Which part would be simplified?

In D4309#122505, @palys-swm wrote:
In D4309#121639, @atul wrote:

As an aside, I think some of the state logic could be extracted into hooks?

Giving names to the hooks which are used might indeed improve the readability. On the other hand, moving the hooks to other place would make the code more scattered, which could make it harder to understand. Will explore it a bit.

After some thought, I don't think extracting these is beneficial. All the values returned by hooks have meaningful names, so the purpose is well-documented. Creating separate hooks would make this code more scattered - it doesn't make too much sense because this is the only place where these will ever be used.

Simplify deselect user callback

This revision was automatically updated to reflect the committed changes.