Transition pairs joined,left and left,joined are now transformed into single meta-transitions "joined_and_left" and "left_and_joined" respectively. These are described as "joined and left", "left and rejoined".
Treat consecutive sequences of transitions as repetitions, and handle any arbitrary repetitions of transitions:
...,joined,left,joined,left,joined,left,...
is canonicalised into
...,joined_and_left, joined_and_left, joined_and_left,...
which is truncated and described as
... , joined and left 3 times, ...
This also works if there are multiple consecutive sequences separated by other transitions:
..., banned, banned, banned, joined, unbanned, unbanned, unbanned,...
becomes
... was banned 3 times, joined, was unbanned 3 times ...
The MELS can now deal with arbitrary sequences of transitions per user, where a transition is a change in membership. A transition can be joined, left, invite_reject, invite_withdrawal, invited, banned, unbanned or kicked.
Repeated segments (modulo 1 and 2), such as joined,left,joined,left,joined will be handled and will be rendered as " ... and 10 others joined and left 2 times and then joined". The repeated segments are assumed to be at the beginning of the sequence. This could be improved to handle arbitrary repeated sequences.
- The MessagePanel now uses the same key for the MELS instances rendered so that entirely new instances are not created, they are simply passed new props (namely when new events arrive).
- MELS itself now uses `shouldComponentUpdate` so that it only updates if it is given a different number of events to previous or if it is toggled to expand.
Also, the net change of nil is detected as having the first and last events being _different_. The summary should only include those that have their first and last events being the _same_ because that is a net change (within the block of member events).
* Fix join/part collapsing regressions
* Simplify loop
* Explain e,e
* Explain return null in _renderSummary
* Kill it properly
* Move . to _renderSummary
* Only use the first and last events to decide whether a net change has occured
* Do not sort events by TS before summarising
* fix loop and comment
* remove data-number-events
* Better explanation comment in _renderSummary
* Less tortuous comment
* Use a list of callbacks for things that need tinting.
Rather than gutwrenching the internals of TintableSVG inside the Tinter.
* Share a data: url for the tinted download svg in MFileBody
* Check image exists before tinting
* Add comments
* Use fetch+DomParser rather than XMLHttpRequest
* Remove comment about XMLHttpRequest