Add react component for Timeline visualization

[MuhammadTalha57]

Status

This PR is currently a draft.

While testing the implementation, I realized the tests I initially wrote don't accurately reflect real parallel execution. I'm updating the test suite to better cover actual parallel behavior before requesting a review.

🤔 What's changed?

This PR adds a Timeline react component for better visualization of parallel runs.

⚡️ What's your motivation?

Fixes #126 .

🏷️ What kind of change is this?

• 🏦 Refactoring/debt/DX (improvement to code design, tooling, etc. without changing behaviour)
• ⚡ New feature (non-breaking change which adds new behaviour)

♻️ Anything particular you want feedback on?

I’d appreciate feedback on adding Timeline component in Report component as opposed to Cucumber-jvm which implements Timeline separately. However Timeline can still be used as separate component.

📋 Checklist:

• I agree to respect and uphold the Cucumber Community Code of Conduct
• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[mpkorstanje]

I’d appreciate feedback on adding Timeline component in Report component as opposed to Cucumber-jvm which implements Timeline separately. However Timeline can still be used as separate component.

I don't think it should go into the main report. It will not be informative most of the time and it doesn't interact with the search component. I think some sort of tab-structure or drop-down menu might be useful here to switch between the different reports.

@davidjgoss thoughts?

[davidjgoss]

This is great, thanks for picking this up.

I appreciate this is still in draft but I'll give some high-level (functionality, not implementation) feedback now in case it's helpful:

• I agree with the tabs approach - I see the timeline as an alternate way to view and navigate the test run, with the list of feature files being the other one
• On that basis, I think selecting a test case should show the full <TestCaseOutcome/> below it, not just a summary - that component should be re-usable, but you might need to add the title yourself
• Where there is only one process, I think the "Main process" label can be dropped entirely
• I'm happy to see the filters and search honoured, though I'd like the timeline axis to remain the full test run time and not contract, so you can see where your matching scenarios are on the whole timeline, if that makes sense

Also, I just landed #528 which if you merge it in here will give you a more realistic sample ("parallel") to work with for testing without hand-crafting anything. This might expose some edge cases for you.

[davidjgoss]

Also, if you have any friction with Query like having to jump through hoops calling multiple methods to get to some bit of data, do flag that up here and we can probably smooth it out. For example some methods accept TestCaseStarted but could also work with TestCaseFinished which is what you're using here.

[MuhammadTalha57]

@davidjgoss Thanks for the feedback.
I have made the following changes:

1. Used vis-timeline js to render timeline (as it is also being used in cucumber-jvm)
2. Added tab based switching.
3. <TestCaseOutcome/> is shown along with the summary.
4. Removed "Main process" label when no worker id is present.
5. Now axis doesn't change on filtering items.

I haven't updated tests as they are not compatible with updated implementation. I think it makes sense to write tests after getting feedback on current implementation.

I want to ask that timeline component should reflect same behavior on searching and filtering as Filtered docs ?
And currently I am just searching based on string matching.
I would appreciate feedback on searching and filtering and hints to implement the same behavior as of Filtered docs.

[mpkorstanje]

Used vis-timeline js to render timeline (as it is also being used in cucumber-jvm)

Oh. You don't have to copy anything from Cucumber JVM. The choice at the time was rather arbitrary. If there are better libraries for rendering graphs and timelines free to use those.

[MuhammadTalha57]

Used vis-timeline js to render timeline (as it is also being used in cucumber-jvm)

Oh. You don't have to copy anything from Cucumber JVM. The choice at the time was rather arbitrary. If there are better libraries for rendering graphs and timelines free to use those.

Actually, I ended up using vis-timeline after exploring a few alternatives.

My first implementation was a custom React component because I thought it would integrate better than a vanilla JavaScript library. However, implementing features like smooth zooming and panning proved more involved than I expected.

I then evaluated React timeline libraries, including react-calendar-timeline, but the ones I tried didn't provide the level of time resolution I needed (for example, zooming down to milliseconds).

After that, I revisited vis-timeline and found it met the requirements while also providing the interaction I was looking for, so I switched to that instead.

If there's another library you'd recommend that would be a better fit for this project, I'd be happy to explore it.

[mpkorstanje]

Mmh. Then we've inherited some problems from the vis-timeline too.

The current design is not very readable. The timeline compresses the pickle names too much.
I don't know what would make it more readable. Perhaps flipping the axis of the timeline could help here? And/or perhaps the text can scale with it.

I don't have quite enough time to look into this much deeper today. But let me know what you think.

[davidjgoss]

Some thoughts on the timeline rendering:

• I would drop the font size to say 0.75em
• The solid background colour based on the status is a bit garish and probably not great for accessibility. Consider matching what we do on the document accordion - pale grey background, normal text, and prepend the coloured status icon - maybe this would make it too hard to distinguish e.g. failures amongst 99% success, but feels worth a shot

The vis-timeline library concerns me due to how much it would inflate the bundle size, along with legacy dependencies like moment. However, I think it's the right thing to be quickly iterating with for now - once we settle on a subset of functionality we need, we can shop around again and/or look at rolling our own if it makes sense.

I want to ask that timeline component should reflect same behavior on searching and filtering as Filtered docs? And currently I am just searching based on string matching.

Good question. We do have all the logic we need for properly searching and filtering already, but it's kind of wrapped up in the "documents" view. I think I can uncouple it from that and make it easier for you though - leave that with me for a day or two.

I haven't updated tests as they are not compatible with updated implementation. I think it makes sense to write tests after getting feedback on current implementation.

Definitely! We're still experimenting at this point.

[MuhammadTalha57]

Thanks for the detailed feedback, I'll get working on these changes and update the PR soon.

[MuhammadTalha57]

I've experimented with a few different UI approaches based on the feedback. Here are the results:

1. Neutral background (no status background color)

2. No labels + tooltip on hover

3. Swapped axes

vis-timeline doesn't support swapping the axes so I used a temporary prototype (generated with AI) to visualize how a vertical timeline might look.

4. Fullscreen mode

I also tried a fullscreen view to provide more horizontal space. In practice, I don't think it significantly improves readability.

My impression is that retaining status colors makes it much easier to scan the timeline although using lighter shades would be better.

I also think supporting both horizontal and vertical orientations could be valuable as each has its own strengths.