Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
10 tasks
kyubisation opened this issue Jan 12, 2024 · 2 comments
Open
10 tasks

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

kyubisation opened this issue Jan 12, 2024 · 2 comments
Assignees
Labels
proposal: accepted team: Draconis Will be done by team Draconis

Comments

@kyubisation
Copy link
Contributor

kyubisation commented Jan 12, 2024

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
@kyubisation kyubisation added the team: Draconis Will be done by team Draconis label Jan 12, 2024
@WalkingOS
Copy link
Contributor

thank you for the specification!

my thoughts:

sbb-pearl-chain:

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
Copy link
Contributor

@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.

@kyubisation kyubisation changed the title story(sbb-pearl-chain): Refactor initial implementation [WIP] story(sbb-pearl-chain): Refactor initial implementation Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal: accepted team: Draconis Will be done by team Draconis
Projects
Status: sbb.ch Priority
Development

No branches or pull requests

3 participants