Deploy preview for PR 2539 🛫

Author: balzss

pr-preview/pr-2539/docs/CHANGELOG.json

@@ -1 +1 @@
-{"description":"\n# Token migration\n\nThe new token system consists of auto-generated tokens form design. They can be imported from `ui-themes`.\n\n## Changing tokens only\n\nThe migration strategy with the least amount of effort is only changing tokens. This approach keeps the component as class-based and retains the `View` component.\n\nChanges needed:\n\n- Import token types from `@instructure/ui-themes` instead of `@instructure/shared-types`\n- Update `generateStyle` function to use `NewComponentTypes['ComponentName']` for the theme parameter\n- Replace old theme tokens with new token names from the design system\n- Replace `@withStyleLegacy` decorator with `@withStyle` and remove `generateComponentTheme`\n- delete `theme.ts`\n\nIf tokens are from a different (usually parent) components, add the `componentID` of that component as second paramater of `@withStyle` and use that name in the `generateStyle` function in `style.ts`: `NewComponentTypes['ParentComponentNameWithTheTokens']`\n\n`generateStyle` accepts a third parameter as well, which are the `sharedTokens`. These provide tokens for shared behaviors such as focus rings, shadows or margins. `'@instructure/emotion'` has various util functions that uses these, such as `calcSpacingFromShorthand` and `calcFocusOutlineStyles`.\n\n## Removing View\n\nFor some components it makes sense to remove the `View` component underneath the component structure. Most of the time, `View` only provides margins, focus rings, or minor visual aid. These can be replicated - in most cases - by the `sharedTokens` and their utils.\n\nIdeally all occurrences of `View` would be eliminated from the codebase.\n\n## Transforming class based components to functional\n\nThe ultimate goal is to migrate all components to functional based ones. Currently it's not a priority and detailed migration guides will be available later. For the time being, `Avatar` or `RadioInput` can be used as starting reference points.\n","title":"Migrating components to new theming system","category":"Contributor Guides","order":1,"relativePath":"docs/contributor-docs/migrating-to-new-tokens.md","extension":".md","srcPath":"docs/contributor-docs/migrating-to-new-tokens.md","srcUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/contributor-docs/migrating-to-new-tokens.md","packageName":"@instructure/docs","requirePath":"@instructure/docs/contributor-docs/migrating-to-new-tokens","requireStr":"require('/home/runner/work/instructure-ui/instructure-ui/docs/contributor-docs/migrating-to-new-tokens.md').default","esPath":"@instructure/docs/contributor-docs/migrating-to-new-tokens","themePath":"docs/contributor-docs/migrating-to-new-tokens.md","themeUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/contributor-docs/migrating-to-new-tokens.md","id":"migrating-to-new-tokens"}
+{"description":"\n# Token migration\n\nThe new token system consists of auto-generated tokens form design. They can be imported from `ui-themes`.\n\n## Changing tokens only\n\nThe migration strategy with the least amount of effort is only changing tokens. This approach keeps the component as class-based and retains the `View` component.\n\nChanges needed:\n\n- Import token types from `@instructure/ui-themes` instead of `@instructure/shared-types`\n- Update `generateStyle` function to use `NewComponentTypes['ComponentName']` for the theme parameter\n- Replace old theme tokens with new token names from the design system\n- Replace `@withStyle` decorator with `@withStyleNew` and remove `generateComponentTheme`\n- delete `theme.ts`\n\nIf tokens are from a different (usually parent) components, add the `componentID` of that component as second paramater of `@withStyleNew` and use that name in the `generateStyle` function in `style.ts`: `NewComponentTypes['ParentComponentNameWithTheTokens']`\n\n`generateStyle` accepts a third parameter as well, which are the `sharedTokens`. These provide tokens for shared behaviors such as focus rings, shadows or margins. `'@instructure/emotion'` has various util functions that uses these, such as `calcSpacingFromShorthand` and `calcFocusOutlineStyles`.\n\n## Removing View\n\nFor some components it makes sense to remove the `View` component underneath the component structure. Most of the time, `View` only provides margins, focus rings, or minor visual aid. These can be replicated - in most cases - by the `sharedTokens` and their utils.\n\nIdeally all occurrences of `View` would be eliminated from the codebase.\n\n## Transforming class based components to functional\n\nThe ultimate goal is to migrate all components to functional based ones. Currently it's not a priority and detailed migration guides will be available later. For the time being, `Avatar` or `RadioInput` can be used as starting reference points.\n","title":"Migrating components to new theming system","category":"Contributor Guides","order":1,"relativePath":"docs/contributor-docs/migrating-to-new-tokens.md","extension":".md","srcPath":"docs/contributor-docs/migrating-to-new-tokens.md","srcUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/contributor-docs/migrating-to-new-tokens.md","packageName":"@instructure/docs","requirePath":"@instructure/docs/contributor-docs/migrating-to-new-tokens","requireStr":"require('/home/runner/work/instructure-ui/instructure-ui/docs/contributor-docs/migrating-to-new-tokens.md').default","esPath":"@instructure/docs/contributor-docs/migrating-to-new-tokens","themePath":"docs/contributor-docs/migrating-to-new-tokens.md","themeUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/contributor-docs/migrating-to-new-tokens.md","id":"migrating-to-new-tokens"}

pr-preview/pr-2539/docs/InstUISettingsProvider.json

@@ -1 +1 @@
-{"description":"\n## Testing\n\nThis page provides an overview of the testing strategies we use to ensure the quality and stability of our components. We use a combination of modern tools to support our testing needs. Each tool serves a different purpose in our testing pyramid.\n\n### Test strategies:\n\n#### Unit tests with Vitest and React Testing Library:\n\nThese tools are our primary stack for writing component-level unit tests. They are lightweight and fast. [Vitest](https://vitest.dev/guide/) is one of the fastest modern testing framework. It offers a Jest-like API and runs in a Node.js environment, making it ideal for testing individual components and functions in isolation. Paired with [React Testing Library](https://testing-library.com/docs/react-testing-library/intro), Vitest encourages accessible and maintainable test practices by querying elements the way users interact with them. It's best suited for testing component logic, rendering conditions, and props/state changes without needing a full browser environment.\n\nFor more information about our unit tests you can check out our [detailed guides and examples.](/#vitest-unit-testing)\n\n#### Component Testing with Cypress:\n\n[Cypress Component Testing](https://docs.cypress.io/app/component-testing/get-started) allows us to mount individual components in a real browser environment for precise interaction testing. Unlike traditional unit tests, it renders with full CSS and browser APIs, offering more realistic behavior. This makes it ideal for testing user interactions like clicks, keyboard navigation, focus traps, and animations. While a bit heavier than Vitest, it provides greate visibility and debugging capabilities for complex UI logic.\n\nFor more information check out our [detailed guides and examples.](cypress-component-testing)\n\n#### Visual Regression Testing with Cypress and Chromatic:\n\nWe use [Cypress](https://docs.cypress.io/app/tooling/visual-testing) end-to-end (e2e) tests to generate structured layouts and capture screenshots of components. [Chromatic](https://www.chromatic.com/docs/diff-inspector/) handles the visual diffing and review process. It's especially effective for catching layout shifts, styling regressions, or broken UI elements that don’t trigger functional test failures. Tests are run after changes are pushed to remote, comparing the new screenshots to a baseline stored from a previously verified state. When differences are detected, the test fails and provides side-by-side diffs for easy review.\n\nThese e2e tests also run [Axe](https://github.com/dequelabs/axe-core) accessibility checks and monitors `console.error`s.\n\nYou can read about these in the [README](https://github.com/instructure/instructure-ui/blob/master/regression-test/README.md) of the regression testing suite.\n","title":"Testing","category":"Contributor Guides/Testing","order":1,"relativePath":"docs/testing/testing-overview.md","extension":".md","srcPath":"docs/testing/testing-overview.md","srcUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/testing/testing-overview.md","packageName":"@instructure/docs","requirePath":"@instructure/docs/testing/testing-overview","requireStr":"require('/home/runner/work/instructure-ui/instructure-ui/docs/testing/testing-overview.md').default","esPath":"@instructure/docs/testing/testing-overview","themePath":"docs/testing/testing-overview.md","themeUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/testing/testing-overview.md","id":"testing-overview"}
+{"description":"\n## Testing\n\nThis page provides an overview of the testing strategies we use to ensure the quality and stability of our components. We use a combination of modern tools to support our testing needs. Each tool serves a different purpose in our testing pyramid.\n\n### Test strategies:\n\n#### Unit tests with Vitest and React Testing Library:\n\nThese tools are our primary stack for writing component-level unit tests. They are lightweight and fast. [Vitest](https://vitest.dev/guide/) is one of the fastest modern testing framework. It offers a Jest-like API and runs in a Node.js environment, making it ideal for testing individual components and functions in isolation. Paired with [React Testing Library](https://testing-library.com/docs/react-testing-library/intro), Vitest encourages accessible and maintainable test practices by querying elements the way users interact with them. It's best suited for testing component logic, rendering conditions, and props/state changes without needing a full browser environment.\n\nFor more information about our unit tests you can check out our [detailed guides and examples.](/#vitest-unit-testing)\n\n#### Component Testing with Cypress:\n\n[Cypress Component Testing](https://docs.cypress.io/app/component-testing/get-started) allows us to mount individual components in a real browser environment for precise interaction testing. Unlike traditional unit tests, it renders with full CSS and browser APIs, offering more realistic behavior. This makes it ideal for testing user interactions like clicks, keyboard navigation, focus traps, and animations. While a bit heavier than Vitest, it provides greate visibility and debugging capabilities for complex UI logic.\n\nFor more information check out our [detailed guides and examples.](cypress-component-testing)\n\n#### Visual Regression Testing with Cypress:\n\nWe use [Cypress](https://docs.cypress.io/app/tooling/visual-testing) end-to-end (e2e) tests to capture screenshots of every component showcase page in the `regression-test` Next.js app. A custom [pixelmatch](https://github.com/mapbox/pixelmatch)-based `ui-scripts visual-diff` command compares each capture against a baseline stored on the `visual-baselines` branch and publishes an interactive HTML report to GitHub Pages for every PR. Tests are run after changes are pushed to remote; when differences are detected, the job fails and the sticky PR comment links to the report with inline diff images.\n\nThese e2e tests also run [Axe](https://github.com/dequelabs/axe-core) accessibility checks and monitor `console.error`s.\n\nFor the full workflow, local dev loop, and how to add a new page, see the [visual regression testing guide](visual-regression).\n","title":"Testing","category":"Contributor Guides/Testing","order":1,"relativePath":"docs/testing/testing-overview.md","extension":".md","srcPath":"docs/testing/testing-overview.md","srcUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/testing/testing-overview.md","packageName":"@instructure/docs","requirePath":"@instructure/docs/testing/testing-overview","requireStr":"require('/home/runner/work/instructure-ui/instructure-ui/docs/testing/testing-overview.md').default","esPath":"@instructure/docs/testing/testing-overview","themePath":"docs/testing/testing-overview.md","themeUrl":"https://github.com/instructure/instructure-ui/tree/master/docs/testing/testing-overview.md","id":"testing-overview"}