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

Showcase/demo: Ideal code structure for atomic-component with Lit #4877

Open
wants to merge 22 commits into
base: master
Choose a base branch
from

Conversation

louis-bompart
Copy link
Collaborator

A showcase of the "all-included" component in a directory approach:

  • component-name/component-name.ts: the component itself
  • component-name/component-name.mdx: the 'usage & more' documentation of the component
  • component-name/component-name.new.stories.tsx: the technical/storybook reference page
  • component-name/component-name.spec.tsx: the unit-tests of the component
  • component-name/e2e/page-object.ts: the playwright/e2e selector associated to this specific component
  • component-name/e2e/fixture.ts: all the selectors & utils required for the end-to-end testing of this component. May use selector of other components.
  • component-name/e2e/componen-name.e2e.ts: the end-to-end tests of the component

Copy link

github-actions bot commented Jan 18, 2025

Pull Request Report

PR Title

❌ Title should follow the conventional commit spec:
<type>(optional scope): <description>

Example: feat(headless): add result-list controller

Live demo links

Bundle Size

File Old (kb) New (kb) Change (%)
case-assist 243.9 243.9 0
commerce 355.1 355.1 0
search 415 415 0
insight 406.3 406.3 0
recommendation 256.2 256.2 0
ssr 408.9 408.9 0
ssr-commerce 372.9 372.9 0

SSR Progress

Use case SSR (#) CSR (#) Progress (%)
search 39 44 89
recommendation 0 4 0
case-assist 0 6 0
insight 0 27 0
commerce 0 15 0
Detailed logs search : buildInteractiveResult
search : buildInteractiveInstantResult
search : buildInteractiveRecentResult
search : buildInteractiveCitation
search : buildGeneratedAnswer
recommendation : missing SSR support
case-assist : missing SSR support
insight : missing SSR support
commerce : missing SSR support

render() {
return html`
<div>
<p>Hello, ${this.name}!</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should showcase localization (of aria-label, too!)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/#naming_techniques when relevant, yes, using a aria-label could make sense.

import {LitElement, html, css} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement('atomic-result-example-component')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sample component should also have a slot and a couple of parts.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes


render() {
return html`
<div>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally our sample components should showcase a few ARIA attributes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhh... I disagree, ARIA Attributes are a bit of a crutch for the web IMO (see the warning in https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still many cases where using ARIA attributes is legit, though, and the current sample might be a little too simple.

@@ -0,0 +1,32 @@
import {LitElement, html, css} from 'lit';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have samples for a result template component and for a non-result template component.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

interface TestFixture {
resultExample: AtomicResultExample;
}
export const test = base.extend<TestFixture & AxeFixture>({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes me wonder: should we test accessibility in UTs or in e2e?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UT minimally, TBD for e2e

import {describe, it, expect} from 'vitest';
import './atomic-result-example-component.js';

describe('atomic-result-example-component', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should UTs also cover localization (at least broadly)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably yes, tbd

@fpbrault
Copy link
Contributor

A showcase of the "all-included" component in a directory approach:

  • component-name/component-name.ts: the component itself
  • component-name/component-name.mdx: the 'usage & more' documentation of the component
  • component-name/component-name.new.stories.tsx: the technical/storybook reference page
  • component-name/component-name.spec.tsx: the unit-tests of the component
  • component-name/e2e/page-object.ts: the playwright/e2e selector associated to this specific component
  • component-name/e2e/fixture.ts: all the selectors & utils required for the end-to-end testing of this component. May use selector of other components.
  • component-name/e2e/componen-name.e2e.ts: the end-to-end tests of the component

I was wondering, is there a specific reason we have "new" in the stories file?

@louis-bompart
Copy link
Collaborator Author

A showcase of the "all-included" component in a directory approach:

  • component-name/component-name.ts: the component itself
  • component-name/component-name.mdx: the 'usage & more' documentation of the component
  • component-name/component-name.new.stories.tsx: the technical/storybook reference page
  • component-name/component-name.spec.tsx: the unit-tests of the component
  • component-name/e2e/page-object.ts: the playwright/e2e selector associated to this specific component
  • component-name/e2e/fixture.ts: all the selectors & utils required for the end-to-end testing of this component. May use selector of other components.
  • component-name/e2e/componen-name.e2e.ts: the end-to-end tests of the component

I was wondering, is there a specific reason we have "new" in the stories file?

We could/should probably remove it now 😂 It was when we did a Storybook revamp/transition

Base automatically changed from chore/dev-mode-niceties to master January 24, 2025 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants