chore: event timeline tooltips #8205
Open
+317
−170
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://linear.app/unleash/issue/2-2664/implement-event-tooltips
Implements event tooltips in the new event timeline.
This leverages our current
feature-event-formatter-md
to provide both a label and a summary of the event. Whenever our neweventTimeline
flag is enabled, we enrich our events in our event search endpoint with this information. We've discussed different options here and reached the conclusion that this is the best path forward for now. This way we are being consistent, DRY, relatively performant and it also gives us a happy path forward if we decide to scope in the event log revamp, since this data will already be present there.We also added a new
label
property to each of our event types currently in our event formatter. This way we can have a concise, human-readable name for each event type, instead of exposing the internal event type string.We also fixed the way the event formatter handled bold text (as in, bold). Before, it was wrapping them in single asterisks, but now we're using double asterisks. We also abstracted this away into a helper method aptly named
bold
. Of course, this change meant that a bunch of snapshots and tests needed to be updated.This new
bold
method also makes it super easy to revert this decision if we choose to, for any reason. However I believe we should stick with markdown formatting, since it is the most commonly supported formatting syntax, so I see this as an important fix. It's also in the name of the formatter (md
). I also believe bold was the original intent. If we want italic formatting we should implement it separately at a later point.