Updates to results spans #112

SergeiGolos · 2025-05-23T21:35:04Z

This pull request introduces significant updates to the Wod.Wiki project, including detailed documentation, enhancements to the EventsView component, and various core architectural changes. The changes aim to improve maintainability, enhance functionality, and align the codebase with updated project requirements.

Documentation Updates:

Added a comprehensive .github/copilot-instructions.md file, detailing the project's architecture, tech stack, core components, coding guidelines, testing approach, and extension points. This serves as a foundational reference for developers.

Enhancements to `EventsView` Component:

Introduced a new EffortRowData interface to encapsulate transformed workout event data, simplifying row rendering logic.
Refactored the EventsView component to preprocess results into transformedResults, consolidating logic for metrics transformation and validation. This reduces redundancy and improves readability. [1] [2]

Core Architectural Changes:

Added a fromString method to the BlockKey class, enabling parsing of string representations into BlockKey instances for better interoperability.
Updated the IRuntimeBlock interface to include a getSpanBuilder method, replacing direct span manipulation methods (spans, addSpan) for improved encapsulation. [1] [2]

Metric and Runtime Updates:

Modified the MetricValue type to remove unused fields (lap, increment) and simplify its structure.
Updated RuntimeMetricEdit and RuntimeSpan to use string-based blockKey identifiers instead of BlockKey instances, streamlining serialization and data handling. [1] [2]

* Initial plan for issue * Implement BlockKey.fromString method and tests Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com> * Updated RuntimeSpan and ResultSpanBuilder to work with BlockKey string serialization Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com>

#51) * Initial plan for issue * Limit BlockKey to RuntimeBlock, use string in RuntimeSpan Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com>

* Initial plan for issue * Fix blockKey in ResultSpan by setting toString value in RuntimeBlock.onStart Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: SergeiGolos <660992+SergeiGolos@users.noreply.github.com>

gemini-code-assist

Hello @SergeiGolos, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Gemini here, providing a summary for this pull request. This PR introduces several key updates to the Wod.Wiki project. The primary goals appear to be enhancing the display and handling of workout results, improving the core runtime's management of result spans, and adding comprehensive documentation for developers.

Highlights

EventsView Component Refactor: The EventsView component has been significantly refactored to use a new EffortRowData interface and preprocess results into a transformedResults array. This simplifies the rendering logic and consolidates metric transformation and validation.
Core Architectural Changes: The BlockKey class now includes a static fromString method for parsing string representations. The IRuntimeBlock interface has been updated to replace direct spans() and addSpan() methods with a single getSpanBuilder() method, promoting better encapsulation of span management within the block.
Metric and Runtime Updates: The MetricValue type has been simplified by removing unused fields (lap, increment, round). RuntimeMetricEdit and RuntimeSpan now use string-based blockKey identifiers instead of BlockKey instances, streamlining serialization and data handling.
Result Span Management: The ResultSpanBuilder has been updated to be block-specific, removing global registry methods. Span creation and stopping logic is now handled directly by the builder instance obtained from a block, and the RuntimeBlock's enter and leave methods are responsible for creating and finalizing/writing spans.

Changelog

Click here to see the changelog

.github/copilot-instructions.md
- Added new file containing comprehensive project documentation for developers.
src/components/metrics/EventsView.tsx
- Added EffortRowData interface to structure transformed result data (lines 12-23).
- Updated sorting logic to correctly use timeSpans start timestamp (lines 31-35).
- Introduced transformedResults array to preprocess and flatten result data before rendering (lines 52-90).
- Refactored table rendering logic to iterate over transformedResults instead of sortedResults (lines 107-246).
src/core/BlockKey.ts
- Added static fromString method to parse string representations of BlockKey (lines 19-51).
src/core/IRuntimeBlock.ts
- Added getSpanBuilder() method (line 11).
- Removed spans() and addSpan() methods (lines 21-22).
src/core/MetricValue.ts
- Removed lap, increment, and round fields from MetricValue type (lines 3-6).
src/core/RuntimeMetricEdit.ts
- Changed blockKey type from BlockKey to string (line 7).
src/core/RuntimeSpan.ts
- Changed blockKey type from BlockKey to string (line 6).
- Added blockId property (line 5).
- Removed children property (line 10).
src/core/tests/BlockKey.spec.ts
- Added new test file for BlockKey string conversion methods.
- Added test for toString formatting (lines 6-17).
- Added test for fromString parsing (lines 19-33).
- Added test for fromString handling empty string (lines 35-42).
- Added test for fromString handling invalid format (lines 44-51).
- Added test for converting BlockKey to string and back (lines 53-71).
src/core/fragments/IncrementFragment.ts
- Removed logic from applyToMetric method (lines 10-12).
src/core/fragments/LapFragment.ts
- Removed logic from applyToMetric method (lines 9-10).
src/core/metrics/ResultSpanBuilder.ts
- Added import for BlockKey (line 6).
- Removed registeredSpans property (line 14).
- Updated Create method signature to accept IRuntimeBlock and set block properties on the span (lines 21-29).
- Updated AddValue method (lines 46-52).
- Updated SetValue method (lines 71-81).
- Updated Stop method to return this instead of throwing an error if no span exists or no timespan to stop (lines 108-115).
- Added Spans() method to return all timespans from all spans (lines 125-131).
- Renamed All() method to Build() and added logic to stop the last timespan if needed before returning spans (lines 149-163).
- Removed ForBlock, registerSpan, registerBlockSpans, getAllSpans, getSpansByBlockKey, getSpansByTimeRange, getSpansByMetric, aggregateMetrics, createHierarchicalView, buildSpanTree, clear methods and SpanNode interface (lines 136-387 in original code).
src/core/metrics/tests/BlockKeySpanIntegration.test.ts
- Added new test file for BlockKey string conversion and its integration with ResultSpanBuilder methods.
- Includes tests for getSpansByBlockKey and createHierarchicalView using both BlockKey objects and string representations (lines 6-99).
- Includes a test for seamless conversion between BlockKey objects and strings (lines 100-128).
src/core/metrics/tests/ResultSpanBuilder.test.ts
- Removed import for SpanNode (line 2).
- Updated mock IRuntimeBlock structure (lines 34-47).
- Updated mock RuntimeSpan to use string blockKey (line 51).
- Updated tests to align with changes in ResultSpanBuilder methods (e.g., Create signature, removal of methods).
src/core/runtime/TimerRuntime.ts
- Removed logic for calling onStart and registering spans during push (lines 105-116 in original code).
- Removed logic for calling onStop and registering spans during pop (lines 125-139 in original code).
- Removed logic for calling next after pop (lines 142-146 in original code).
src/core/runtime/actions/StartTimerAction.ts
- Removed imports for SetResultSpanAction, ResultSpan, RuntimeSpan, ITimeSpan (lines 5-8).
- Removed detailed logic for creating/updating RuntimeSpan and ResultSpan within applyBlock, now relying on the block's onStart and internal builder (lines 27-81 in original code).
src/core/runtime/actions/StopTimerAction.ts
- Removed detailed logic for stopping RuntimeSpan and creating/updating ResultSpan within applyBlock, now relying on the block's onStop and internal builder (lines 39-68 in original code).
- Removed fallback logic for updating clock without ResultSpan (lines 70-74 in original code).
src/core/runtime/blocks/DoneRuntimeBlock.ts
- Removed import for WriteResultAction (line 11).
- Removed logic for creating WriteResultAction in onLeave (lines 43-46 in original code).
src/core/runtime/blocks/EffortBlock.ts
- Removed import for WriteResultAction (line 6).
- Removed SetTimerStateAction and WriteResultAction from the actions returned by onLeave (lines 55-56 in original code).
src/core/runtime/blocks/RepeatingBlock.ts
- Removed import for WriteResultAction (line 9).
- Removed WriteResultAction from the actions returned by onLeave (line 73 in original code).
src/core/runtime/blocks/RootBlock.ts
- Removed import for StartHandler (line 13).
- Minor change in onEnter signature and usage of runtime parameter (line 43).
- Removed commented-out line in onLeave (line 70).
src/core/runtime/blocks/RuntimeBlock.ts
- Removed imports for RuntimeSpan, IMetricCompositionStrategy, ITimeSpan (lines 8, 12, 13).
- Added import for WriteResultAction (line 11).
- Removed _spans, spans(), addSpan(), and metricCompositionStrategy properties/methods (lines 33-45 in original code).
- Updated getSpanBuilder to return the builder directly (removed ForBlock call) (line 37).
- Updated enter method to call spanBuilder.Create and metrics (lines 59-60).
- Updated leave method to call spanBuilder.Build and add WriteResultAction to returned actions (line 70).
- Updated onStart method to use spanBuilder.Start() (line 155).
- Updated onStop method to use spanBuilder.Stop() (line 162).
- Removed metric composition strategy logic from metrics method (lines 237-239 in original code).
src/core/runtime/inputs/TickHandler.ts
- Updated to use block?.getSpanBuilder().Spans() to get time spans (line 20).
src/core/runtime/outputs/SetClockAction.ts
- Updated to use block.getSpanBuilder().Spans() to get time spans for TimeSpanDuration (line 22).
src/core/runtime/outputs/WriteResultAction.ts
- Updated console log message to use result?.index instead of result.blockKey?.index (line 34).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

A block begins its run,
Metrics gathered, one by one.
Spans start and cease,
Bringing data peace,
When the runtime's work is done.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This PR brings some valuable refactoring, especially in centralizing span management within RuntimeBlock and simplifying related actions. The new BlockKey.fromString method and the documentation file are good additions.

However, there are critical inconsistencies between the API changes in ResultSpanBuilder / RuntimeSpan and the test files that use them. Additionally, a few potential runtime errors need to be addressed. These issues make the PR not ready for merge in its current state.

Summary of Findings

API Inconsistency & Test Mismatches: Critical inconsistencies exist between API changes in ResultSpanBuilder.ts / RuntimeSpan.ts (method/property removals) and test files (BlockKeySpanIntegration.test.ts, ResultSpanBuilder.test.ts) that still use the old API. Tests are likely broken or invalid.
Potential Runtime Error in EventsView.tsx: Usage of row.index! in EventsView.tsx may cause runtime errors if index is undefined, as it's an optional property.
Potential Type Mismatch in TickHandler.ts: The derivation of timeSpans in TickHandler.ts seems to result in a single ITimeSpan object, while downstream consumers (like TimeSpanDuration via SetClockAction) might expect ITimeSpan[].
Behavioral Change in ResultSpanBuilder.Stop(): ResultSpanBuilder.Stop() now fails silently instead of throwing errors, which could mask issues.
Semantic Change in BlockKey Handling: Removal of BlockKey.create(this) call in RuntimeBlock.enter() might change how hierarchical block keys are formed. Clarification is needed.
Simplification of MetricValue: The MetricValue type was simplified by removing lap, increment types and the round field. This was noted but not commented on due to review settings (low severity).
String-based BlockKeys: RuntimeMetricEdit and RuntimeSpan now use string-based blockKey identifiers. This was noted but not commented on due to review settings (low severity).
Centralized Span Management: The shift to getSpanBuilder() in IRuntimeBlock and RuntimeBlock centralizes span creation and management, simplifying actions like StartTimerAction and StopTimerAction. This is a positive change.

Merge Readiness

This pull request has some excellent refactoring aimed at improving span management. However, due to the critical inconsistencies found between the API changes (especially in ResultSpanBuilder and RuntimeSpan) and the test files that rely on the previous API, along with other high-severity potential runtime issues, I recommend that these changes not be merged in their current state. The identified critical and high severity issues should be addressed first. As an AI, I cannot approve PRs; please ensure thorough review and approval by human reviewers after these issues are resolved.

gemini-code-assist · 2025-05-23T21:39:50Z

src/core/metrics/ResultSpanBuilder.ts

-
-        if (timeSpan.stop) {
-          timeSpan.stop.blockKey = block.blockKey.toString();
+  public Build(): RuntimeSpan[] {


This PR introduces significant changes by removing several methods from ResultSpanBuilder, such as registerSpan, getAllSpans, getSpansByBlockKey, createHierarchicalView, and clear.

However, the newly added test file src/core/metrics/__tests__/BlockKeySpanIntegration.test.ts and the modified src/core/metrics/__tests__/ResultSpanBuilder.test.ts still make extensive use of these removed methods. This creates a critical inconsistency.

Could you please clarify the intended state of the ResultSpanBuilder API?

If these methods are meant to be removed, the tests need to be updated or removed accordingly.

If the methods were removed unintentionally or if their functionality is still needed, they should be reinstated or their equivalents provided.

gemini-code-assist · 2025-05-23T21:39:50Z

src/core/RuntimeSpan.ts

+  blockKey?: string;
  index?: number;
  timeSpans: ITimeSpan[] = [];
-  metrics: RuntimeMetric[] = [];
-  children: string[] = []; // Added children property
-  leaf?: boolean; // marker if span comes from a leaf-level block
+  metrics: RuntimeMetric[] = [];  
+  leaf?: boolean;  


The children: string[] property has been removed from RuntimeSpan. This is a significant change, especially if it was used for building hierarchical span views.

This change, combined with the removal of createHierarchicalView from ResultSpanBuilder, seems to indicate a shift in how span hierarchies are handled. However, the newly added test file src/core/metrics/__tests__/BlockKeySpanIntegration.test.ts (e.g., line 74) still attempts to use rootSpan.children.

This is a critical inconsistency. Please reconcile the RuntimeSpan data model with the tests and clarify how span relationships/hierarchies are intended to be managed going forward.

gemini-code-assist · 2025-05-23T21:39:50Z

src/core/metrics/__tests__/BlockKeySpanIntegration.test.ts

+    const spansWithString = builder.getSpansByBlockKey(blockKeyString);
+    expect(spansWithString).toHaveLength(1);
+  });
+
+  test('should handle string blockKey in getSpansByBlockKey', () => {
+    // Arrange
+    const builder = new ResultSpanBuilder();
+
+    // Create a RuntimeSpan with string blockKey
+    const span = new RuntimeSpan();
+    span.blockKey = '1,2(0)';
+    span.metrics = [];
+
+    // Register the span
+    builder.registerSpan(span);
+
+    // Act & Assert
+    // Test with string
+    const spansWithString = builder.getSpansByBlockKey('1,2(0)');
+    expect(spansWithString).toHaveLength(1);
+
+    // Test with BlockKey object
+    const blockKey = BlockKey.fromString('1,2(0)');
+    const spansWithBlockKey = builder.getSpansByBlockKey(blockKey);
+    expect(spansWithBlockKey).toHaveLength(1);
+  });
+
+  test('should handle BlockKey objects in createHierarchicalView', () => {
+    // Arrange
+    const builder = new ResultSpanBuilder();
+8000
+    // Create BlockKeys
+    const rootBlockKey = new BlockKey();
+    rootBlockKey.push([{ id: 1 }] as any, 0);
+    const rootBlockKeyString = rootBlockKey.toString();
+
+    const childBlockKey = new BlockKey();
+    childBlockKey.push([{ id: 2 }] as any, 0);
+    const childBlockKeyString = childBlockKey.toString();
+
+    // Create a root RuntimeSpan with string blockKey
+    const rootSpan = new RuntimeSpan();
+    rootSpan.blockKey = rootBlockKeyString;
+    rootSpan.metrics = [];
+    rootSpan.children = [childBlockKeyString];
+
+    // Create a child RuntimeSpan with string blockKey
+    const childSpan = new RuntimeSpan();
+    childSpan.blockKey = childBlockKeyString;
+    childSpan.metrics = [];
+
+    // Register the spans
+    builder.registerSpan(rootSpan);
+    builder.registerSpan(childSpan);
+
+    // Act
+    // Test with BlockKey object
+    const hierarchyWithBlockKey = builder.createHierarchicalView(rootBlockKey);
+
+    // Test with string
+    const hierarchyWithString = builder.createHierarchicalView(rootBlockKeyString);
+
+    // Assert
+    expect(hierarchyWithBlockKey.children).toHaveLength(1);
+    expect(hierarchyWithString.children).toHaveLength(1);
+
+    // Check child nodes
+    expect(hierarchyWithBlockKey.children[0].children).toHaveLength(1);
+    expect(hierarchyWithString.children[0].children).toHaveLength(1);
+  });
+
+  test('should convert between BlockKey and string seamlessly', () => {
+    // Arrange
+    const originalBlockKey = new BlockKey();
+    originalBlockKey.push([{ id: 10 }, { id: 20 }] as any, 5);
+
+    const stringRepresentation = originalBlockKey.toString();
+    const recreatedBlockKey = BlockKey.fromString(stringRepresentation);
+
+    // Act
+    const builder = new ResultSpanBuilder();
+
+    // Create spans with different representations of the same BlockKey as strings
+    const spanWithOriginalKey = new RuntimeSpan();
+    spanWithOriginalKey.blockKey = originalBlockKey.toString();
+
+    const spanWithStringKey = new RuntimeSpan();
+    spanWithStringKey.blockKey = stringRepresentation;
+
+    const spanWithRecreatedKey = new RuntimeSpan();
+    spanWithRecreatedKey.blockKey = recreatedBlockKey.toString();
+
+    builder.registerSpan(spanWithOriginalKey);
+
+    // Assert - all should match the original key
+    expect(builder.getSpansByBlockKey(originalBlockKey)).toHaveLength(1);
+    expect(builder.getSpansByBlockKey(stringRepresentation)).toHaveLength(1);
+    expect(builder.getSpansByBlockKey(recreatedBlockKey)).toHaveLength(1);
+  });
+});


This new test file appears to be out of sync with the API changes made in ResultSpanBuilder.ts and RuntimeSpan.ts within this same pull request.

Specifically:

It uses methods like builder.registerSpan(), builder.getSpa 8000 nsByBlockKey(), and builder.createHierarchicalView() which seem to have been removed from ResultSpanBuilder.ts.

It attempts to assign to rootSpan.children, but the children property has been removed from RuntimeSpan.ts.

These tests will likely fail or are testing a non-existent API. This needs to be addressed by either updating the tests to reflect the new API or by revisiting the API changes in ResultSpanBuilder and RuntimeSpan.

gemini-code-assist · 2025-05-23T21:39:50Z

src/components/metrics/EventsView.tsx

-                                index={result.index!}                      
-                                validate={validationSchema}
+                                blockKey={row.blockKey} 
+                                index={row.index!}                      


The index property on row (derived from RuntimeSpan.index) is optional (index?: number in EffortRowData and RuntimeSpan). Using the non-null assertion operator ! here could lead to a runtime error if row.index is indeed undefined.

Could you clarify if index is guaranteed to be present for rows that reach this part of the code? If not, this should be handled more safely, perhaps by:

Ensuring index is always populated during the transformedResults creation if it's essential.

Passing row.index without ! and letting EditableMetricCell handle a potentially undefined index.

Providing a default value or conditional rendering if index is undefined.

This concern also applies to lines 221 and 233.

gemini-code-assist · 2025-05-23T21:39:51Z

src/core/runtime/inputs/TickHandler.ts

+    const spans = block?.getSpanBuilder().Spans();
    const timeSpans = spans && spans.length > 0 
-      ? spans[spans.length - 1].timeSpans
+      ? spans[spans.length - 1]
      : [];


There seems to be a change in how timeSpans is derived here.
Previously, spans would be RuntimeSpan[], spans[spans.length - 1] would be the last RuntimeSpan, and then .timeSpans would access its ITimeSpan[].

Now, block?.getSpanBuilder().Spans() returns ITimeSpan[]. So, spans (in this context of your new code) is ITimeSpan[].
Then, spans[spans.length - 1] (on line 22) would refer to the last individual ITimeSpan object in that array, not an array of time spans.

If durationFragment.duration(block.blockKey, timeSpans) (line 26) or any subsequent logic expects timeSpans to be an array (ITimeSpan[]), this change will likely cause a type error or incorrect behavior. For instance, SetClockAction uses TimeSpanDuration which expects ITimeSpan[].

Could you verify the expected type for the timeSpans argument in durationFragment.duration() and ensure it's consistent with this derivation?

gemini-code-assist · 2025-05-23T21:39:51Z

src/core/metrics/ResultSpanBuilder.ts

  public Stop(): ResultSpanBuilder {
    if (!this.currentSpan) {
-      throw new Error("No current span exists. Call Create() first.");
+      return this
    }


The behavior of Stop() has changed from throwing an error (if !this.currentSpan) to returning this (a silent no-op). While this can make the method more resilient, it might also hide potential issues where Stop() is called inappropriately.

Was this change in error handling intentional? It's worth considering if an explicit error or a console warning might be more appropriate for debugging if Stop() is called in an unexpected state.

gemini-code-assist · 2025-05-23T21:39:51Z

src/core/runtime/blocks/RuntimeBlock.ts

-    // Space for common code to run before the specific block's onEnter logic
-    this.blockKey = BlockKey.create(this);
-    console.log(`>>>>> doEnter >>>>>: ${this.blockKey} -- ${this.constructor.name}`);
+  public enter(runtime: ITimerRuntime): IRuntimeAction[] {    


In the enter method, the line this.blockKey = BlockKey.create(this); was previously present (in an older version or a similar context) and responsible for creating/updating the full hierarchical BlockKey by traversing parent blocks. This line has been removed.

The BlockKey is initialized in the constructor with this.blockKey.push(this.sources, 0);. If BlockKey.create(this) is no longer called upon entering a block, how is the blockKey intended to reflect its full path in the runtime stack, especially for nested blocks?

Could you clarify the intended mechanism for BlockKey to represent the block's hierarchical context? If this change means blockKey is now simpler and doesn't store the full parent path, that's a valid design choice, but its implications should be understood.

SergeiGolos and others added 7 commits May 23, 2025 12:28

updated terminal errror

baf4f5c

instruction file

cf0ab48

fixed results data structure

00286cf

fixed the composition of results

82fb092

SergeiGolos merged commit 55eb3e3 into bitcobblers:main May 23, 2025
2 checks passed

gemini-code-assist bot reviewed May 23, 2025

View reviewed changes

gemini-code-assist bot suggested changes May 23, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Updates to results spans #112

Updates to results spans #112

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Updates to results spans #112

Updates to results spans #112

Uh oh!

Conversation

Documentation Updates:

Enhancements to EventsView Component:

Core Architectural Changes:

Metric and Runtime Updates:

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Summary of Changes

Highlights

Changelog

Footnotes

Uh oh!

Choose a reason for hiding this comment

Code Review

Summary of Findings

Merge Readiness

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Enhancements to `EventsView` Component: