story(sbb-pearl-chain): Refactor initial implementation

[kyubisation]

Feature Description

We want to refactor the pearl chain to be more idiomatic to web components.

<sbb-pearl-chain>:

• Should have properties arrival and departure
  • Should be getter/setter, which accept SbbDateLike | null
  • Defaults to null
  • See date parsing logic below
  • If the date cannot be parsed in the setter, assign null
  • If defined and valid, render as <time> elements in the Shadow DOM (similar to how it is now)
• It should handle the logic for the progress of a journey
  • If a leg is in the past, mark it as past
  • If a leg is active, pass in the width of the gray overlay via CSS variable
  • The active marker should be a (pseudo) element in the Shadow DOM and placed relatively to the passed time (match with width of gray overlay). Should not be shown for cancelled legs.
  • Create property marker: 'static' | 'pulsing' = 'static', which controls whether the active state marker should pulse or not (static)
  • If the journey is in the past, mark all legs as past and unsubscribe from setInterval
  • If the journey is in the future or currently active, assign the active marker and related logic/styles
• With the attribute data-now, it should be possible to override the current time
• When the whole trip is cancelled, only one leg (cancelled) should be display. This is left to the consumer and should be documented in the readme.

<sbb-pearl-chain-leg>:

• Should have boolean properties disruption, past and string property skip: 'departure' | 'arrival' = 'departure'
  • TODO: Define/Ask for business logic for possible combinations. In invalid combinations fall back to sensible defaults.
• Should have properties arrival and departure
  • Should be getter/setter, which accept SbbDateLike | null
• Width should be defined with the CSS property --sbb-pearl-chain-leg-weight, which is applied to the flex rule flex: var(--sbb-pearl-chain-leg-weight, 1) var(--sbb-pearl-chain-leg-weight, 1); (see example https://stackblitz.com/edit/js-vjmxgz?file=style.css) (This allows just subtracting the departure Date from the arrival Date and setting this value as --sbb-pearl-chain-leg-weight and flex will automatically calculate width)

DOM Examples

Without time being displayed

<sbb-pearl-chain>
  <sbb-pearl-chain-leg departure="2024-01-31T16:53:00.000Z" arrival="2024-01-31T17:53:00.000Z"></sbb-pearl-chain-leg>
  <sbb-pearl-chain-leg departure="2024-01-31T17:58:00.000Z" arrival="2024-01-31T19:45:00.000Z" disruption></sbb-pearl-chain-leg>
  <sbb-pearl-chain-leg departure="2024-01-31T19:52:00.000Z" arrival="2024-01-31T19:58:00.000Z"></sbb-pearl-chain-leg>
</sbb-pearl-chain>

With time being displayed

<sbb-pearl-chain departure="2024-01-31T16:53:00.000Z" arrival="2024-01-31T19:58:00.000Z">
  <sbb-pearl-chain-leg departure="2024-01-31T16:53:00.000Z" arrival="2024-01-31T17:53:00.000Z"></sbb-pearl-chain-leg>
  <sbb-pearl-chain-leg departure="2024-01-31T17:58:00.000Z" arrival="2024-01-31T19:45:00.000Z" disruption></sbb-pearl-chain-leg>
  <sbb-pearl-chain-leg departure="2024-01-31T19:52:00.000Z" arrival="2024-01-31T19:58:00.000Z"></sbb-pearl-chain-leg>
</sbb-pearl-chain>

Definition of Done

• [ ] Component is implemented
• [ ] Documentation is provided
• [ ] Tests are implemented
• [ ] E2E Tests are implemented
• [ ] Storybook stories are implemented
• [ ] Navigation via keyboard is tested
• [ ] Screen reader output is tested
• [ ] High-contrast is tested
• [ ] Remaining accessibility is tested
• [ ] UX approved

[WalkingOS]

thank you for the specification!

my thoughts:

sbb-pearl-chain:

• all legs are cancelled: https://lyne-storybook.app.sbb.ch/?path=/story/timetable-sbb-pearl-chain--cancelled
• makes also sense for active state and cancelled -> If its cancelled there should be no active state (currently buggy)
• disableAnimation prop is missing: active state without pulse animation

sbb-pearl-chain-leg:

• is it like one leg = one dot (left side) and one line?
• should handle: first leg departure dot is bigger and last leg arrival dot is bigger (type: 'start-end' | 'stop')
• Business logic should be for the lines and dots: 'default' < 'past' < 'skipped' < 'disruption';

-Question about 'skipped': 'Skipped' can represent either the departure stop or the arrival stop. Should the leg siblings be aware of each skipped property, or should we implement it with two separate properties: 'departureSkipped' and 'arrivalSkipped'?

[jeripeierSBB]

@kyubisation . Thanks for writing the specification. It looks good for me in general. Some topics:

• Attributes on closing tags seem not really supported, but it's only a detail :)
• timer: The concept basically sound good, I'm just wondering if this is really a performance boost. As a drawback it could be that because all changes are handled with one event synchronous, it could also block/slowdown ui for a short time. This timer could also be used for the sbb-clock maybe.
• data-now: I think we should mention also, that for testing purposes it should be possible to set the current date by "data-now" (similar to other components).

@WalkingOS I think it's better to use arrivalSkipped and departureSkipped.