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 · May be fixed by #3172
Open
10 tasks

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

kyubisation opened this issue Jan 12, 2024 · 2 comments · May be fixed by #3172
Assignees
Labels
complexity: L Can be done in a fortnight proposal: accepted

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>:

After discussion, we decided to exclude arrival and departure properties from sbb-pearl-chain, but we will later create designated components like sbb-pearl-chain-time.

  • 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 now, it should be possible to override the current time

  • When the whole trip is cancelled, only one leg (cancelled) should be displayed. 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)
  • A leg is considered in the past, if the arrival is before "now"

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
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
@jeripeierSBB jeripeierSBB moved this from Funnel to sbb.ch Priority in ESTA Web Lyne Design System May 15, 2024
@kyubisation kyubisation removed the team: Draconis Will be done by team Draconis label Jul 25, 2024
@kyubisation kyubisation moved this from sbb.ch Priority to Next in ESTA Web Lyne Design System Jul 25, 2024
@kyubisation kyubisation added the complexity: L Can be done in a fortnight label Jul 26, 2024
@MarioCastigliano MarioCastigliano self-assigned this Aug 16, 2024
@TomMenga TomMenga moved this from Next to In progress in ESTA Web Lyne Design System Aug 28, 2024
@MarioCastigliano MarioCastigliano linked a pull request Oct 24, 2024 that will close this issue
28 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: L Can be done in a fortnight proposal: accepted
Projects
Status: In progress
Development

Successfully merging a pull request may close this issue.

4 participants