@royaloperahouse/harmonic 1.0.4 → 1.0.5-b

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,7 @@
1
1
  import React from 'react';
2
2
  import { ThemeType } from '../../types';
3
3
  import './theme/fonts.css';
4
+ import './theme/typography.css';
4
5
  export declare const DEFAULT_THEME = ThemeType.Core;
5
6
  interface HarmonicThemeProviderProps {
6
7
  theme: ThemeType;
@@ -17,4 +17,8 @@ export interface ModalWindowProps extends Modal.Props {
17
17
  * ID of the app element to assist with accessibility.
18
18
  */
19
19
  appElementId?: string;
20
+ /**
21
+ * Accessible label for the close button.
22
+ */
23
+ closeButtonAriaLabel?: string;
20
24
  }
@@ -147,6 +147,10 @@ export interface ITabProps {
147
147
  * Additional CSS class names to apply to the navigation component.
148
148
  */
149
149
  className?: string;
150
+ /**
151
+ * The unique ID to assign to the link element.
152
+ */
153
+ tabLinkId?: string;
150
154
  /**
151
155
  * Defines the ARIA role of the element for accessibility purposes.
152
156
  */
@@ -222,7 +226,11 @@ export interface IDropdownProps {
222
226
  */
223
227
  ariaLabel?: string;
224
228
  /**
225
- * Defines if it is needed to trim the text of the Tab and add 3 dots in the end
229
+ * The unique ID to assign to the link element inside the tab.
230
+ */
231
+ tabLinkId?: string;
232
+ /**
233
+ * Defines if it is needed to trim the text of the Tab and add 3 dots in the end
226
234
  */
227
235
  trimTabText?: boolean;
228
236
  }
@@ -429,7 +437,15 @@ export declare type IHotFilterProps = {
429
437
  selectedIndex?: number;
430
438
  onSelect?: (index: number) => void;
431
439
  };
432
- export declare type ICastFilterItem = Pick<AnchorHTMLAttributes<HTMLAnchorElement>, 'aria-label' | 'role'> & {
440
+ export declare type ICastFilterItem = {
441
+ /**
442
+ * Stable identifier for selection mapping and rendering keys.
443
+ */
444
+ id?: string | number;
445
+ /**
446
+ * Alternative stable identifier for selection mapping and rendering keys.
447
+ */
448
+ slug?: string;
433
449
  /**
434
450
  * Name of the cast member shown below the image circle. Required.
435
451
  */
@@ -438,6 +454,15 @@ export declare type ICastFilterItem = Pick<AnchorHTMLAttributes<HTMLAnchorElemen
438
454
  * Image source for the image to be shown. Optional but if not included an unaesthetic placeholder will show.
439
455
  */
440
456
  image?: string;
457
+ /**
458
+ * Optional accessible name for the option. If omitted, `name` is used.
459
+ */
460
+ 'aria-label'?: string;
461
+ /**
462
+ * Kept for backwards compatibility with existing integrations.
463
+ * CastFilter always renders option semantics and ignores this value at runtime.
464
+ */
465
+ role?: string;
441
466
  onClick?: () => void;
442
467
  };
443
468
  export declare type ICastFiltersProps = {
@@ -448,8 +473,14 @@ export declare type ICastFiltersProps = {
448
473
  cast: ICastFilterItem[];
449
474
  /**
450
475
  * Indices of currently selected cast in the `cast` array.
476
+ * Legacy API kept for backwards compatibility.
451
477
  */
452
478
  selectedIndices?: number[];
479
+ /**
480
+ * Stable IDs/slugs of currently selected cast items.
481
+ * Prefer this over `selectedIndices` for stable selection across reordering.
482
+ */
483
+ selectedIds?: Array<string | number>;
453
484
  /**
454
485
  * Text shown at the top of the component, e.g. 'Filter by cast'. If this is not provided
455
486
  * the component will render without any.
@@ -479,12 +510,22 @@ export declare type ICastFiltersProps = {
479
510
  listRoleDescription?: string;
480
511
  /**
481
512
  * Handle selecting individual cast filters.
513
+ * Legacy API kept for backwards compatibility.
482
514
  */
483
515
  onSelect?: (index: number) => void;
516
+ /**
517
+ * Handle selecting individual cast filters using stable item ID/slug.
518
+ */
519
+ onSelectId?: (id: string) => void;
484
520
  /**
485
521
  * Handle clicking the primary CTA.
522
+ * Legacy API kept for backwards compatibility.
486
523
  */
487
524
  onApply?: (indices: number[]) => void;
525
+ /**
526
+ * Handle clicking the primary CTA using stable selected IDs/slugs.
527
+ */
528
+ onApplyIds?: (ids: string[]) => void;
488
529
  /**
489
530
  * Handle clicking the text link.
490
531
  */
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@royaloperahouse/harmonic",
3
- "version": "1.0.4",
3
+ "version": "1.0.5-b",
4
4
  "author": "Royal Opera House",
5
5
  "license": "MIT",
6
6
  "main": "dist/index.js",
package/README.GIT DELETED
@@ -1,293 +0,0 @@
1
- # Royal Opera House Harmonic - Front End Design System
2
-
3
- Welcome to The Royal Opera House Front End Design System, `@royaloperahouse/harmonic`
4
-
5
- This package is a library of UI components intended to be used in the ROH website.
6
-
7
- It uses React, TypeScript, TSDX and Storybook.
8
-
9
- The NPM packages are published at [Royal Opera House - Harmonic](https://www.npmjs.com/package/@royaloperahouse/harmonic)
10
-
11
- The Storybook for the latest version of the library is hosted at [Storybook - Harmonic] TODO: S3 deployment
12
-
13
-
14
- ## Prerequisites
15
- ---
16
-
17
- * Make sure the required package dependencies are installed using `yarn install`
18
- * If this is the first time you are working on Harmonic, make sure to run `yarn build` to build all the modules.
19
-
20
- * **To deploy the storybook publicly** you will need credentials for the **parent** 'Royal Opera House' AWS account in your `~/.aws/credentials` file.
21
- * The deploy script expects these to be called `[parent]`.
22
-
23
- * You can find these values at:
24
-
25
- *AWS access portal/ Accounts tab -> 'Royal Opera House' -> 'Access keys' -> 'Option 2: Add a profile to your AWS credentials file'*
26
-
27
- * **To deploy a preview** for demo / QA you will need:
28
-
29
- * A Chromatic account with a **Developer** role in the `roh-ml` project in Chromatic
30
- * [Mari Lovell](mari.lovell@roh.org.uk) is the current owner of this project, you can contact her to invite you
31
- * The `CHROMATIC_PROJECT_TOKEN` -- find this in 1Password or ask the project owner.
32
-
33
-
34
- * **To enable publishing to the NPM package**:
35
- * Create account / log in to NPM
36
- * Ask a colleague with admin rights to be added as a contributer
37
- * Generate your own ROH `NPM_TOKEN` (store this token in 1Password)
38
- * Set up Two-Factor Authentication for NPM, as you will be prompted by the publishing script
39
-
40
-
41
- ## Versioning
42
- ---
43
- > NOTE: The following applies while the Harmonic project is in Alpha (before a version 1.0.0 release)
44
-
45
- We are **not** yet using semantic versioning.
46
-
47
- When proposing changes to the Harmonic library, increment the patch version (the last number) by one, **only** in the changelog (alternatively, leave the version in the changelog as TBC) along with a note about your changes.
48
-
49
- Only increment the version in the package.json for releasing snapshots.
50
-
51
- Once your changes are merged to the main branch and released in a new version, the release manager will be responsible for incrementing that release version.
52
-
53
- > NOTE: The following **may** apply once the Harmonic project is out of Alpha, but is subject to change before then.
54
-
55
- We use [Semantic Versioning](https://semver.org/) for Harmonic.
56
-
57
- Given a version number MAJOR.MINOR.PATCH, increment the:
58
-
59
- * MAJOR version when you make incompatible library changes
60
- * MINOR version when you add functionality in a backwards compatible manner
61
- * PATCH version when you make backwards compatible bug fixes
62
-
63
- When you create a new release always update the `CHANGELOG` and `package.json`
64
-
65
- Increment your version from the latest stable version on [Royal Opera House - Harmonic](https://www.npmjs.com/package/@royaloperahouse/harmonic?activeTab=versions)
66
-
67
-
68
- ## Deploying the Storybook
69
- ---
70
-
71
- ### **1. To build and deploy locally**
72
-
73
- You can quickly build and serve the contents of `/storybook-static` from your local machine, for development and manual testing. To do this run:
74
-
75
- ```bash
76
- yarn storybook
77
- ```
78
-
79
- By default the storybook will be accessible at
80
- [http://localhost:6006/]()
81
-
82
- The server will hot-reload on most changes.
83
-
84
- ### **2. To deploy a preview version remotely**
85
-
86
- You can deploy a release candidate, or work-in-progress to [Chromatic](https://www.chromatic.com/) for showcase or QA.
87
-
88
- **NOTE:** you will need the `CHROMATIC_PROJECT_TOKEN` and to be invited as a contributor to the Harmonic project in Chromatic, as described in *Prerequisites* above.
89
-
90
- Either set the token as a shell variable or use a `.env` file in the `harmonic` root directory containing the token, as so:
91
-
92
- ```
93
- CHROMATIC_PROJECT_TOKEN=tokengoeshere
94
- ```
95
-
96
- Run:
97
- ```
98
- CHROMATIC_PROJECT_TOKEN=tokengoeshere yarn deploy-storybook-dev
99
- ```
100
-
101
- to build and deploy the storybook from your repo to Chromatic.
102
-
103
- You will find the address of your deployed storybook in the console output, looking something like this:
104
-
105
- `→ View your Storybook at https://randomHexString-randomAlphabeticalString.chromatic.com`
106
-
107
- ### **3. To deploy a release version**
108
-
109
- You can deploy the contents of `./storybook-static` to S3 as a static site, which is permanently accessible at [WIP] TODO: S3 deployment
110
-
111
- **NOTE:** To do this you will need the correct `AWS` credentials set up, as described in *Prerequisites* above.
112
-
113
- First build the storybook using:
114
-
115
- ```
116
- yarn build-storybook
117
- ```
118
-
119
- then run:
120
-
121
- ```bash
122
- yarn deploy-storybook
123
- ```
124
-
125
- > **IMPORTANT:** This URL is intended to showcase the latest stable version of Harmonic, it should be kept up to date with the `main` Harmonic branch and should **only** be used for release versions. If you want to deploy a development version follow the steps above under *To deploy a preview version remotely*.
126
-
127
-
128
- ## Releasing a New Package Version
129
- ---
130
-
131
- This is the procedure for releasing a new Harmonic NPM package.
132
-
133
- There are two types of package:
134
-
135
- A **snapshot** can be published to use a development version of the Harmonic library in our frontend staging environments, to perform integrated, manual testing.
136
-
137
- A **stable** package is published for use in production.
138
-
139
- **NOTE:** You will need the `NPM_TOKEN`, as described in 'Prerequisites' above.
140
-
141
- ### **1. To release a snapshot version**
142
-
143
- > **IMPORTANT:** Make sure you always publish your **snapshots** from `development` after merging in your feature branch.
144
-
145
- For snapshots, `RELEASE_VERSION` should be the same as the latest **stable** version of the Harmonic Library, as found in [npm Harmonic - Versions](https://www.npmjs.com/package/@royaloperahouse/harmonic?activeTab=versions), followed by an **unused** lowercase letter.
146
-
147
- For example, if the latest stable release was 1.42.0, and the last snapshot published to NPM was 1.42.0-w, you would use RELEASE_VERSION `1.42.0-x`
148
-
149
- To publish a snapshot use:
150
-
151
- ```bash
152
- NPM_ROH_TOKEN={NPM_TOKEN} RELEASE_VERSION={RELEASE_VERSION} yarn publish-snapshot
153
- ```
154
- Use the version name to install the package in a frontend repo.
155
-
156
- ### **2. To release a stable version**
157
-
158
- > **IMPORTANT:** Make sure you always publish your **stable** packages from `main` after merging in your feature branch.
159
-
160
- For stable releases, increment your version from the latest **stable** version found on [npm Harmonic - Versions](https://www.npmjs.com/package/@royaloperahouse/harmonic?activeTab=versions), following the rules described in *Versioning* above, and use this as `RELEASE_VERSION`. (Make sure it matches the version in your `package.json` and `CHANGELOG.md`!)
161
-
162
- To publish a stable package use:
163
-
164
- ```bash
165
- NPM_ROH_TOKEN={NPM_TOKEN} RELEASE_VERSION={RELEASE_VERSION} yarn publish-release
166
- ```
167
-
168
-
169
- ## Using the Package
170
- ---
171
-
172
- The package is deployed to NPM, and can be installed using yarn or npm:
173
-
174
- ```bash
175
- npm i --save @royaloperahouse/harmonic
176
- ```
177
- ```bash
178
- yarn add @royaloperahouse/harmonic
179
- ```
180
-
181
-
182
- ## Testing
183
- ---
184
-
185
- To **Lint** the package use:
186
-
187
- ```bash
188
- yarn lint
189
- # Use the --fix option to perform automatic fixes
190
- ```
191
-
192
- To run the **unit tests** (using Jest) use:
193
-
194
- ```bash
195
- yarn test
196
-
197
- # Use the -u option to update snapshots if needed
198
- # Run `yarn test:watch` to re-run tests on changes
199
- ```
200
-
201
- To **run and and store the unit tests** for display in storybook use:
202
-
203
- ```bash
204
- yarn test-storybook
205
- # Use the -u option to update snapshots if needed
206
- ```
207
-
208
-
209
- ## Development Process
210
- ---
211
-
212
- ### **1. Branching Model**
213
- * The Harmonic project lives in the `harmonic-library/harmonic` *repository*
214
- * When working on Harmonic, treat the `harmonic` directory as your root
215
- * The Harmonic **development** branch is for QA
216
- * The Harmonic **main** branch is currently for stable releases
217
- * All work should be done on a correctly named **feature branch** of the format: `issueType/ticketNumber-short-description-of-feature`, e.g. `feature/RD-12345-add-example-component`
218
- * Always create your feature branch FROM, and submit pull requests TO, the **main** branch
219
- * For **QA / UAT** of a Harmonic component in isolation: following review you should deploy a preview version to Chromatic straight from your **feature branch** _without_ merging to development
220
- * For releasing an **NPM snapshot**: merge your feature branch into the **development** branch and publish the NPM snapshot from there
221
-
222
- ### **2. Detailed Workflow**
223
-
224
- #### **Before review:**
225
-
226
- * Git pull the latest version of Harmonic from `main`
227
- * Checkout a new, correctly-named feature branch from `main`
228
- * Do your work on this feature branch
229
- * Run: `yarn lint --fix`
230
- * Run: `yarn test -u`
231
- * Commit your changes
232
- * Create a pull request from your feature branch to `main`
233
- * Add the appropriate reviewers
234
-
235
- #### **Before QA / UAT:**
236
-
237
- After your PR is approved, you have two options:
238
-
239
- **i.** For QA of a component in isolation:
240
-
241
- * Follow the steps above in *Deploying the Storybook -> 2. Deploying a preview version remotely*
242
- * Share the generated Chromatic URL with the appropriate people for QA / UAT
243
-
244
- **ii.** For integrated testing of a component in the frontend staging environments:
245
-
246
- * Check out the `development` branch
247
- * Merge your work in to `development`
248
- * Follow the steps above under *Publishing a New Package Version -> 1. To release a snapshot version*
249
- * Git push the updated `development` branch to remote
250
- * Finally, in the frontend repo:
251
-
252
- 1. Update the `package.json` to reference the new snapshot version
253
- 2. Run: `yarn install`
254
- 3. Deploy the frontend to a staging environment
255
-
256
- #### **When ready for production:**
257
-
258
- * Return to your Harmonic **feature branch**
259
- * Update the HArmonic version in `package.json`, incrementing from the last **stable** release, found in [npm Harmonic - Versions](https://www.npmjs.com/package/@royaloperahouse/harmonic?activeTab=versions), and following the rules described in the *Versioning* section
260
- * Update `CHANGELOG.md`, adding the new version number and a short description of your changes
261
- * Run: `yarn lint --fix`
262
- * Run: `yarn test -u`
263
- * Run: `yarn test-storybook -u`
264
- * Run: `yarn build-storybook`
265
- * Git commit, push, and update your PR for final approval
266
- * Merge your approved PR to `main`
267
- * Follow the steps in *Publishing a New Package Version -> 2. To release a stable version* to publish the NPM package
268
- * Finally, follow the steps in *Deploying The Storybook -> 3. To deploy a release version*, to update the public Harmonic Storybook page
269
-
270
- Once you have successfully published a new release version, you can open a ticket to update to this version in any of the frontend repos.
271
-
272
-
273
- ## Notes
274
- ---
275
- ### The `storybook-static` folder
276
-
277
- This folder contains all the HTML / JS required to deploy the Storybook as a static site. It's autogenerated whenever the Storybook is built and therefore will show up a lot of merge conflicts when you merge other branches into your feature branch. It is best to leave generating the storybook until the later part of your workflow, but in case you run into conflicts earlier, it's ok to just delete the folder and regenerate using:
278
-
279
- ```bash
280
- yarn build-storybook
281
- ```
282
-
283
- For the same reason changes to this folder will cause a lot of big diffs, when looking at a PR, but can mostly be skimmed over unless something looks unusual.
284
-
285
- ---
286
- ### Examples
287
-
288
- There is an example implementation in the example folder. Alternatively there are also integration examples in storybook. Make sure to keep these updated so as to showcase the current components available.
289
-
290
- ---
291
- ### Bundle analysis
292
-
293
- Calculate the real cost of your library using [size-limit](https://github.com/ai/size-limit) with `yarn size` and visualize it with `yarn analyze`.