address nits

It seems like if we want to sequence this one prior to ENG-6138, we'll need to separate out the types of ThreadStore between web and native. Might be easier to just do the web migration first. Let me know if I'm missing something

remove accidental newlines

Was going to try to see if I could do some more flow refactoring to remove the two invariants that were introduced to thread-reducer, but figured it'd be good to put up what I had that resolved all flow issues.

Personally think it's fine you snuck the color name change in this diff, but in the future we should definitely make a note of that in the Summary section and annotate the change in the diff.

Outside the scope of this diff, but don't love how the search result cell extends beyond the width of the search field.

Changes looks good

Looks good, question inline about wrapping ChatMessageListContainer with <> </>

In D10568#305645, @ashoat wrote:

I don't love that this value is hard-coded... not enough context here to suggest a better way to do it, though

Looks good

Changes described in summary look good.

Hm, radio button doesn't have much contrast when selected. Guessing that component will get updated later as part of this work?

This would bring forward a bunch of dependencies, right?

Noticed a lot of repeated babel stuff when skimming the lock file. Ran yarn-deduplicate locally and got: https://gist.githubusercontent.com/atulsmadhugiri/95f82a4eafb53cffde598e92408e70c7/raw/31fad69447478cf8900df284de7f591675c56bd1/gistfile1.txt

Looks good, make sure to link Linear task before landing

Following the migration, don't we have a guarantee that the store contains only MinimallyEncodedRawThreadInfo?

Rubberstamping

Looks good

Looks good

Looks good, but adding @ashoat as blocking to get sign off on design/product question before landing.

Nit, but let's make sure that we change inActiveTabHeader to inactiveTabHeader before landing

Looks like there might be a regression with the info icon not appearing correctly in the Delete tab:

Looks good

Looks good

Looks good

Some thoughts inline, but good to land as is.

Seems reasonable, thanks for including the video in the Test Plan!

Should we also update "eslint-plugin-jest" and flow-typed/npm/jest_v26.x.x.js?

Seems reasonable

Seems correct, but would appreciate a bit of clarity on use of generics in Props<T: string> to make sure I'm understanding things correctly

Makes sense.

re-open

Re-landing with useNativeDriver removed, created task for converting animation to use Reanimated: https://linear.app/comm/issue/ENG-6348/consider-converting-disconnectedbar-animation-to-reanimated

remove useNativeDriver

re-open

In D10500#303769, @ginsu wrote:

Left a comment about using React.Children.* APIs which are listed as "legacy" in the React docs.

I read through the alternative solutions to the React.Children API in the link you attached in your comments above and felt that the methods outlined here were the best alternative
https://react.dev/reference/react/Children#accepting-an-array-of-objects-as-a-prop

I have confirmed that everything still works with this new alternative solution.

In regards to changing the name of this component from "Card" to "Panel" I mentioned earlier that I wasn't sold on the naming convention either but was struggling to come up with something better. I think "Panel" does fit better for this component; however, with that said we already do have a "Panel" color family that is used other places. I think it would be better to rename that old panel color family to "frame" (based on the screenshots you sent me that is what we use the old panel family for). If there is no opposition to using that name I will update the naming convention in a follow up diff.

Also updated the test plan to show screenshots of safari and firefox

Thanks for addressing feedback

Looks good, but we should try to remove "hard coded" debugging values. Feel free to re-request changes if there's something I'm missing.

Maybe I'm missing something, but it looks like the message list is missing in the screenshots provided. Guessing this was just for debugging layout or something?

Have pretty much zero context on how notifications work on Windows, but this seems like a reasonable flip the switch diff. (Would make sense to get another accept before landing if there's more going on here)

I don't have much context on E2EE Web notifications or the cryptosystem, but this seems like a reasonable "flip the switch" diff.

I don't have much context on E2EE MacOS notifications or the cryptosystem, but this seems like a reasonable "flip the switch" diff.

Left a comment about using React.Children.* APIs which are listed as "legacy" in the React docs.

Looks good, thanks for tidying things up.

Looks good

If I'm understanding this query correctly, we're counting the number of differential.revision.close transactions. Not sure if this is a big deal, but I believe if someone were to

In D10476#302697, @ashoat wrote:

More context on Linear, but I wonder if we can rename useDisconnectedBarVisibilityHandler to something more appropriate, and have it take a keyserver parameter in place of ashoatKeyserverID. Might be best for a separate diff though

Thanks for annotating the SQL query, helped a lot in understanding what was going on.

Seems reasonable, just a note about making tooltipMarginStyle more concise.