Didn't review too carefully, looks like a straightforward rename diff.

rebase and land

resolve merge conflicts and land

rebase and land

rebase and land

address merge conflicts

rebase and land

address merge conflicts and land

rebase before landing

rebase before landing

rebase and land

rebase and land

resolve merge conflicts before landing

rebase and land

address feedback + land

rebase before landing

rebase and land

Thanks for going through and addressing feedback!

Looks good, thanks for addressing feedback!

Thanks for going through and addressing feedback!

Open to either though, it’s just a question of whether we want to prioritize landing first or updating the designs

Thanks for going through and addressing all the feedback!

rebase before landing

Much cleaner!

Let's move logic for construction of message to lib so it can be used across web and native.

Only thing blocking this diff is awaiting the call to callDeleteCommunityRole(...) before calling popModal(...).

Left a couple comments inline. The two that should be addressed before this diff can be accepted:

1. Move isDeletableRole and isEditableRole logic to role-utils.
2. Merge items and roleMenuItems into a single React.useMemo.

Let's see if we can

1. Use a $ReadOnlySet instead of $ReadOnlyArray for pendingRolePermissions.
2. Break apart modifyUserSurfacedPermissionOptions(...) into separate functions with clear and descriptive names.

(Resigning since encrypted notifications are a blindspot for me, feel free to re-add if there's something specific I can be useful for)

Passing back to remove setTimeout

Didn't look at implementation of deleteRole(...), but this looks correct assuming that deleteRole(...) is.

Something to note about the reduxThreadInfo line of code is that it's used so after creating a role, then returning back to this modal, we want to pull in the latest ThreadInfo from the redux store so the modal can show the newly created role in the list of roles. Without this (as was a similar case in native), the new role will only show once the modal is closed and re-opened, since the props have not changed.

We should make sure that the request is complete before dismissing the modal.

Sweet, thanks for updating so quickly

Can we go with O(n) approach instead of O(n^2)?

Consolidating ops-related code in lib/ops is a much cleaner way of organizing things

Makes sense to decouple types this way

Cleanup by fitting up existing logic into this interface
Make a "contract" for needed utils for future Data Stores
I think it's better to use a method from descriptive object rather than calling random util functions

Re-requesting review because I don't think I need it if I'm landing the entire stack at once

Shouldn't we add some sort of isDev check so we don't roll out this dummy button to users when a keyserver release is made?

Adding @tomek and @ashoat as reviewers since I haven't worked with any of the height measurement stuff

Looks straightforward

Would be good to get signoff from @tomek or @marcin before landing

This looks correct to me. However, my C++ is rusty—particularly w/ templates—so it'd be good to get someone else to sign off before landing (@marcin or @tomek?)