Using nullish coalescing instead of possiblyChangedValue to avoid various flow issues with possiblyChangedValue (there are various value types in queuedChanges and threadInfo which makes things hard to type)

Also generally think it's a cleaner solution that avoids unnecessary (imo) redirection to a helper function that was probably (?) written before widespread support for nullish coalescing?

So for me the solution with the function was slightly better, but not sure if it's worth to reintroduce it.

That makes sense. Given the size of the stack it'll definitely be easier to re-introduce possiblyChangedValue at the end of the stack. I'll leave a comment here linking to that diff once it's put up.

I made the threadDescriptionValue prop a non-optional string so we need to add an empty string at the end in case queuedChanges.description and threadInfo.description are null/undefined.

I can instead make threadDescriptionValue an optional string if that's cleaner