Move to lib

Can you provide more justification as to why this state needs to exist globally versus just being inside a local React component?

In D7335#218238, @atul wrote:

Would be great to test a MULTIMEDIA message with eg 1 video, 1 video + 1 image, 2 videos in addition to photos mentioned in Test Plan (if not done already)

Yeah I had the same thought last time I saw this. Let's remove it

However, I think building the toast will take some time and shouldn't be a priority rn

Thanks for combining the diffs for me!

Nice! Might be worth syncing with Ted... ideally this stuff is covered in designs and you don't have to "wing out", and I don't have to call out the UX issues.

In D7320#218118, @atul wrote:

In D7320#217782, @ashoat wrote:

Can you please include the actual changes instead of submitting a diff that only changes types?

Included changes in D7332. Combining these changes made my workflow more difficult:

Personally would prefer to be able to get these scaffolding type diffs out of the way so I don't need to constantly reposition things.

Two quick notes:

Add signatures for @anunay's new methods

Looks simple

Note that an alternative to a flow-typed library would be to type the library directly. If the code instead the library has // @flow annotations, the libdef would not be necessary. Not sure if that's easier or harder though... could be harder to do if the library is largely codegenned code

Wow this is complicated. I imagine it will be hard for somebody else to recreate this if ever necessary, but appreciate your annotations – hopefully they will be helpful

@kuba, can you rebase this on master so that it includes the un-revert of your reverted diff?

It's unclear in the video what happens when you save.

Ohhhh got it now!

No review is necessary for reverts

In D7313#217779, @atul wrote:

Does it make sense to just remove EDIT_THREAD_NAME permissions for threadTypes.PERSONAL now, so we don't have to run another migration for that?

Maybe, but wouldn't that mean those who've already changed the name of a PERSONAL/PRIVATE thread wouldn't be able to change it back?

Can you please combine this diff into the one that updates Flow types, and the upcoming one that will change the actual code? Your pattern of submitting tiny diffs makes it hard to review your changes

I can't tell what the issue is in the before video

You have a pattern of submitting tiny diffs... I find these hard to review because I don't see the context of your changes. Can you please include the actual changes instead of submitting a diff that only changes types?

Does it make sense to just remove EDIT_THREAD_NAME permissions for threadTypes.PERSONAL now, so we don't have to run another migration for that?

@kuba has not made it clear, but it appears that this diff solves a push-blocking issue: ENG-3584

My feedback appears to have been addressed. Defer to @atul on the redux-persist migration

Might've been helpful to have a link to a Gist or something so I could quickly do a side-by-side, have caught minor discrepancies in the past that way.

Thanks for fixing this so quickly!

I'm guessing it was put there because it's only there to prevent Flow errors in the return, but this is fine

yarn.lock

Yes, chat messages shouldn't be rendered before cleanup (or at least cache reading should be disabled)

In D7077#216716, @inka wrote:

are we are deciding between "hello+goodbye" being treated as one word "hellogoodbye", versus being split into two words "hello goodbye"?

No, with this approach "hello+bye" is parsed to "hello + bye", because segmenter splits them, and .replaceAll doesn't remove the +, since it doesn't match the punctuationRegex. So any of

+ < = > ^ ` | ~

would be left

I'm requesting review, since my goal cannot be landed anyway until I solve setting db variables for all team members

As an aside, do we think we'll be storing additional tokens in Redux in the future?