* Update the pinned message banner when a pinned message is edited
The pinned events are fetched from a memo keyed on the pinned event ids, and editing a
pinned message leaves those ids untouched. Nothing invalidated the memo, so the banner
and the pinned messages card went on rendering the original text while the timeline
showed the edit.
Edits landing on a pinned event now invalidate it. An edit to any other event is
ignored, so an active room does not refetch the pinned set on every message.
* Address review: apply pinned edits in place instead of refetching
The counter that forced the memo to recompute was never read by the memo, so the
dependency array had to carry a variable that meant nothing to the computation.
The edit event is already in hand when the timeline fires, so holding onto it
rather than a tally gives the memo something it can actually consume.
Applying that edit to the fetched copy also removes a round-trip: the pinned set
was being fetched again purely to pick up content the client already had. It has
to run in an effect rather than in the memo because replacing an event notifies
whatever is rendering it, and that must not happen during a render.
The tests now assert the content the hook hands back rather than the number of
fetches, which is what the banner actually shows.
hayyaksiandGitHub
400bf348ef