[native] Barebones user selection in `CommunityCreationMembers`
ClosedPublic
Actions

Authored by atul on Jun 1 2023, 1:13 PM.

Details

Reviewers

ashoat
ginsu

Commits

rCOMM9a3b372c57b2: [native] Barebones user selection in `CommunityCreationMembers`

Summary

Extremely barebones user selection screen in CommunityCreationMembers using TagInput and UserList.

There's a warning about nested scroll views, the styling isn't correct, and we aren't differentiating between COMMUNITY_ROOT and COMMUNITY_ANNOUNCEMENT_ROOT. Going to handle each of those in followup diffs to keep changes easier to review.

Test Plan

Works as expected:

Diff Detail

Repository

rCOMM Comm

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

atul created this revision.Jun 1 2023, 1:13 PM

Herald added a subscriber: tomek. · View Herald TranscriptJun 1 2023, 1:13 PM

atul edited the test plan for this revision. (Show Details)Jun 1 2023, 1:13 PM

atul added a child revision: D8057: [native] Introduce `CommunityCreationContentContainer` component.Jun 1 2023, 1:31 PM

Harbormaster completed remote builds in B19961: Diff 27369.Jun 1 2023, 1:33 PM

atul requested review of this revision.Jun 1 2023, 1:33 PM

Back to you with questions:

Do we really need another low-level component for this? Don't we have something we can reuse? If not, can't we refactor something / make it generic, rather than implementing a new one of these?
Why do we need to differentiate between COMMUNITY_ROOT and COMMUNITY_ANNOUNCEMENT_ROOT?

This revision now requires changes to proceed.Jun 1 2023, 1:35 PM

Do we really need another low-level component for this? Don't we have something we can reuse? If not, can't we refactor something / make it generic, rather than implementing a new one of these?

We're reusing TagInput and UserList which "do a lot," but agree it makes sense to have some general-purpose component with TagInput and UserList "contained" within. At the moment there is no such higher level component we can just drop in here. I can try to pull something generic out of CommunityCreationMembers and see if it can be used in other components where we have TagInput and UserList (ComposeSubchannel, AddUsersModal, etc) later in this stack.

Why do we need to differentiate between COMMUNITY_ROOT and COMMUNITY_ANNOUNCEMENT_ROOT?

The last argument to getPotentialMemberItems(...) is threadType. My understanding is there's no "need" to differentiate at the moment, but might as well pass the correct threadType to the function since we're able to?

In D8056#239034, @atul wrote:

I can try to pull something generic out of CommunityCreationMembers and see if it can be used in other components where we have TagInput and UserList (ComposeSubchannel, AddUsersModal, etc) later in this stack.

That would be great

The last argument to getPotentialMemberItems(...) is threadType. My understanding is there's no "need" to differentiate at the moment, but might as well pass the correct threadType to the function since we're able to?

Thanks for explaining!

This revision is now accepted and ready to land.Jun 1 2023, 1:59 PM

In D8056#239068, @ashoat wrote:

In D8056#239034, @atul wrote:

I can try to pull something generic out of CommunityCreationMembers and see if it can be used in other components where we have TagInput and UserList (ComposeSubchannel, AddUsersModal, etc) later in this stack.

That would be great