chore(docs): consolidate the developer resource files into a docs/ directory (#29266)
Start your review here 👉 [docs/README.md](https://github.com/ionic-team/ionic-framework/blob/FW-6107/docs/README.md) ## What is the current behavior? Documentation files with information on how to contribute, component implementations, testing, etc. are scattered throughout various folders in this repository. ## What is the new behavior? Consolidates the documentation files into a root `docs/` directory for easier discovery and organization. `/docs` tree: ``` ├── _config.yml ├── component-guide.md ├── CONTRIBUTING.md ├── README.md ├── sass-guidelines.md ├── angular │ ├── README.md │ └── testing.md ├── core │ ├── README.md │ └── testing │ ├── README.md │ ├── api.md │ ├── best-practices.md │ ├── preview-changes.md │ └── usage-instructions.md ├── react │ ├── README.md │ └── testing.md ├── react-router │ ├── README.md │ └── testing.md ├── vue │ ├── README.md │ └── testing.md └── vue-router ├── README.md └── testing.md ``` **Migrates the following:** | Previous Location | New Location | | ----------------------------------------------------------- | ----------------------------------------- | | `.github/COMPONENT-GUIDE.md` | `docs/component-guide.md` | | `.github/CONTRIBUTING.md` | `docs/CONTRIBUTING.md` | | `core/scripts/README.md` | `docs/core/testing/preview-changes.md` | | `core/src/utils/test/playwright/docs/api.md` | `docs/core/testing/api.md` | | `core/src/utils/test/playwright/docs/best-practices.md` | `docs/core/testing/best-practices.md` | | `core/src/utils/test/playwright/docs/README.md` | `docs/core/testing/README.md` | | `core/src/utils/test/playwright/docs/usage-instructions.md` | `docs/core/testing/usage-instructions.md` | | `packages/angular/test/README.md` | `docs/angular/testing.md` | | `packages/react-router/test/README.md` | `docs/react-router/testing.md` | | `packages/react/test/README.md` | `docs/react/testing.md` | | `packages/react/test/base/README.md` | `docs/react/testing.md` | | `packages/vue/test/README.md` | `docs/vue/testing.md` | **Adds the following:** | File | Description | | ----------------------------- | ----------------------------------------------------------------------- | | `docs/sass-guidelines.md` | Sass Variable guidelines taken from `ionic-framework-design-documents` | | `docs/README.md` | Entry file that should link to all other files | | `docs/_config.yml` | Config file for use with GitHub pages | | `docs/core/README.md` | Description of core, links to contributing and testing | | `docs/angular/README.md` | Description of angular, links to contributing and testing | | `docs/react/README.md` | Description of react, links to contributing and testing | | `docs/react-router/README.md` | Description of react-router, links to contributing and testing | | `docs/vue/README.md` | Description of vue, links to contributing and testing | | `docs/vue-router/README.md` | Description of vue-router, links to contributing and testing | | `docs/vue-router/testing.md` | Testing file for vue-router, populated from vue-router's main README | **Does not** add any files for `angular-server`. This is because the README is essentially empty and there is no testing in that directory. I can add blank files if we want to have something to add to later. **Does not** migrate the content of the packages' root `README.md` files. These files are used for their npm package descriptions so we should not edit them. ## Hosting Documentation We can (and should) host these files using GitHub Pages. I have duplicated them in a personal repository to see how this would look: [docs-consolidation](https://brandyscarney.github.io/docs-consolidation/). Doing so will require some formatting fixes (see [Sass Guidelines](https://brandyscarney.github.io/docs-consolidation/sass-guidelines.html#-reusable-values)) so I did not publish them now but we can easily enable GitHub pages by toggling a setting in this repository. ## Other information - Verify that no documentation files were missed in the migration - You can use these commands to search for `*.md` files in a directory: - `find core/src -type f -name "*.md" -print` - `find packages/angular -type f -name "*.md" -not -path "**/node_modules/*" -print` - I did add some redirect links in some of the existing markdown files so they might still exist for that reason - We should probably break up the contributing + component guide documentation into smaller files, such as including best practices, but I wanted to get everything in the same place first - The contributing has sections on each of the packages that we could move to that package's docs folder: https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#core --------- Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
This commit is contained in:
Brandy Carney
GitHub
parent
7b6c330f17
commit
b315b0cb29
|
|
@ -25,7 +25,7 @@ Issue number: resolves #
|
|||
If this introduces a breaking change:
|
||||
1. Describe the impact and migration path for existing applications below.
|
||||
2. Update the BREAKING.md file with the breaking change.
|
||||
3. Add "BREAKING CHANGE: [...]" to the commit description when merging. See https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer for more information.
|
||||
3. Add "BREAKING CHANGE: [...]" to the commit description when merging. See https://github.com/ionic-team/ionic-framework/blob/main/docs/CONTRIBUTING.md#footer for more information.
|
||||
-->
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
<a href="https://github.com/ionic-team/ionic-framework/blob/main/LICENSE">
|
||||
<img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="Ionic Framework is released under the MIT license." />
|
||||
</a>
|
||||
<a href="https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md">
|
||||
<a href="https://github.com/ionic-team/ionic/blob/main/docs/CONTRIBUTING.md">
|
||||
<img src="https://img.shields.io/badge/PRs-welcome-brightgreen.svg" alt="PRs welcome!" />
|
||||
</a>
|
||||
<a href="https://twitter.com/Ionicframework">
|
||||
|
|
@ -38,7 +38,7 @@
|
|||
Documentation
|
||||
</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md">Contribute</a>
|
||||
<a href="https://github.com/ionic-team/ionic/blob/main/docs/CONTRIBUTING.md">Contribute</a>
|
||||
<span> · </span>
|
||||
<a href="https://blog.ionicframework.com/">Blog</a>
|
||||
<br />
|
||||
|
|
@ -88,7 +88,7 @@ The Ionic Conference App is a full featured Ionic app. It is the perfect startin
|
|||
### Contributing
|
||||
|
||||
Thanks for your interest in contributing! Read up on our guidelines for
|
||||
[contributing](https://github.com/ionic-team/ionic/blob/main/.github/CONTRIBUTING.md)
|
||||
[contributing](https://github.com/ionic-team/ionic/blob/main/docs/CONTRIBUTING.md)
|
||||
and then look through our issues with a [help wanted](https://github.com/ionic-team/ionic/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
|
||||
label.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,44 +1,4 @@
|
|||
|
||||
## Build
|
||||
# Core Scripts
|
||||
|
||||
### 1. Clone ionic
|
||||
|
||||
git@github.com:ionic-team/ionic.git
|
||||
cd ionic
|
||||
|
||||
### 2. Run `npm install`
|
||||
|
||||
cd core
|
||||
npm install
|
||||
|
||||
|
||||
Notice that `@ionic/core` lives in `core`.
|
||||
|
||||
### 3. Run `npm start`
|
||||
|
||||
Make sure you are inside the `core` directory.
|
||||
|
||||
npm start
|
||||
|
||||
With the `dev` command, Ionic components will be built with [Stencil](https://stenciljs.com/), changes to source files are watched, a local http server will startup, and http://localhost:3333/ will open in a browser.
|
||||
|
||||
### 4. Preview
|
||||
|
||||
Navigate to http://localhost:3333/src/components/. Each component has small e2e apps found in the `test` directory, for example: http://localhost:3333/src/components/button/test/basic
|
||||
|
||||
As changes are made in an editor to source files, the e2e app will live-reload.
|
||||
|
||||
## How to contribute
|
||||
|
||||
1. `npm start` allows you to modify the components and have live reloading, just like another ionic app.
|
||||
|
||||
2. When everything looks good, run `npm run validate` to verify the tests linter and production build passes.
|
||||
|
||||
|
||||
# Deploy
|
||||
|
||||
1. `npm run prepare.deploy`
|
||||
2. Review/update changelog
|
||||
3. Commit updates using the package name and version number as the commit message.
|
||||
4. `npm run deploy`
|
||||
5. :tada:
|
||||
This file has been moved to [/docs/core/testing/preview-changes.md](/docs/core/testing/preview-changes.md).
|
||||
|
|
|
|||
|
|
@ -1,11 +1,3 @@
|
|||
# Ionic E2E Tests Guide
|
||||
|
||||
This directory contains information on how to get the most out of Ionic's E2E test infrastructure when writing tests.
|
||||
|
||||
## Directory
|
||||
|
||||
| Directory | Description |
|
||||
| - | - |
|
||||
| [Usage Instructions](./usage-instructions.md) | How to run tests and update screenshots |
|
||||
| [Best Practices](./best-practices.md) | Contains information on conventions to follow as well as pitfalls to avoid when writing tests |
|
||||
| [API](./api.md) | Documents the custom functionality that has been built on top of Playwright |
|
||||
Refer to the [Core Testing documentation](/docs/core/testing/README.md) in order to build and run the e2e tests.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Contributing
|
||||
|
||||
Thanks for your interest in contributing to the Ionic Framework! :tada:
|
||||
Thanks for your interest in contributing to the Ionic Framework! 🎉
|
||||
|
||||
- [Contributing Etiquette](#contributing-etiquette)
|
||||
- [Creating an Issue](#creating-an-issue)
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
<p align="center">
|
||||
<img alt="Ionic Logo" src="https://github.com/ionic-team/ionic-framework/blob/main/.github/assets/logo.png?raw=true" width="60" />
|
||||
</p>
|
||||
|
||||
<h1 align="center">
|
||||
Ionic Framework Developer Resources
|
||||
</h1>
|
||||
|
||||
<p align="center">
|
||||
This documentation includes guidelines on contributing, coding conventions, best practices, testing steps, and more. It should serve as a collective resource for all documentation related to developing Ionic Framework.
|
||||
</p>
|
||||
|
||||
## What is Ionic Framework?
|
||||
|
||||
Ionic Framework is an open source app development toolkit for building modern, fast, top-quality cross-platform native and Progressive Web Apps from a single codebase with JavaScript and the Web.
|
||||
|
||||
It is based on <a href="https://www.webcomponents.org/introduction">Web Components</a>, which enables significant performance, usability, and feature improvements alongside support for popular web frameworks like <a href="https://angular.io/">Angular</a>, <a href="https://reactjs.com/">React</a>, and <a href="https://vuejs.org/">Vue</a>.
|
||||
|
||||
## Guides
|
||||
|
||||
| Guide | Description |
|
||||
| ----------------------------------------| ---------------------------------------------------------------------------------------- |
|
||||
| [Contributing](./CONTRIBUTING.md) | How to contribute including creating pull requests, commit message guidelines, and more. |
|
||||
| [Component Guide](./component-guide.md) | Guidelines for implementing component states, accessibility, and more. |
|
||||
| [Sass Guidelines](./sass-guidelines.md) | Outlines scenarios where Sass members and comments should be used. |
|
||||
|
||||
## Packages
|
||||
|
||||
| Project | Package | Documentation | Guides |
|
||||
| ---------------- | -------------------------------------------------------------------------- | ---------------------------------| ----------------------------------------------------------------- |
|
||||
| **Core** | [`@ionic/core`](https://www.npmjs.com/package/@ionic/core) | [Readme](core/README.md) | [Testing](core/testing/README.md) |
|
||||
| **Angular** | [`@ionic/angular`](https://www.npmjs.com/package/@ionic/angular) | [Readme](angular/README.md) | [Testing](angular/testing.md) |
|
||||
| **React** | [`@ionic/react`](https://www.npmjs.com/package/@ionic/react) | [Readme](react/README.md) | [Testing](react/testing.md) |
|
||||
| **React Router** | [`@ionic/react-router`](https://www.npmjs.com/package/@ionic/react-router) | [Readme](react-router/README.md) | [Testing](react-router/testing.md) |
|
||||
| **Vue** | [`@ionic/vue`](https://www.npmjs.com/package/@ionic/vue) | [Readme](vue/README.md) | [Testing](vue/testing.md) |
|
||||
| **Vue Router** | [`@ionic/vue-router`](https://www.npmjs.com/package/@ionic/vue-router) | [Readme](vue-router/README.md) | [Testing](vue-router/testing.md) |
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
name: Ionic Framework
|
||||
include: [ CONTRIBUTING.md ]
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Ionic Angular
|
||||
|
||||
The [@ionic/angular](https://www.npmjs.com/package/@ionic/angular) package builds on top of [@ionic/core](https://www.npmjs.com/package/@ionic/core) components.
|
||||
|
||||
## Contributing
|
||||
|
||||
See our [Contributing Guide](/docs/CONTRIBUTING.md).
|
||||
|
||||
## Testing
|
||||
|
||||
Refer to the [Angular Testing documentation](./testing.md) for testing the Angular package.
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
# Angular Testing
|
||||
|
||||
Ionic Framework supports multiple versions of Angular. As a result, we need to verify that Ionic works correctly with each of these Angular versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The Angular test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. Build the `core` and `packages/angular` directories using `npm run build`.
|
||||
2. [Build the Angular test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app directory (e.g. `packages/angular/test/build/ng14`).
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to [wipe or disable the application cache](#application-cache).
|
||||
|
||||
## Application Cache
|
||||
|
||||
Angular CLI creates a cache of several files on disk by default in the `.angular` directory. This decreases the time taken to build the test application. However, the cache makes it difficult to quickly sync and check local changes of Ionic. As a result, the `.angular` cache is disabled by default in the test app projects.
|
||||
|
||||
See https://angular.io/cli/cache for more information.
|
||||
|
||||
### Disable Cache
|
||||
|
||||
```shell
|
||||
ng cache disable
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> You may need to manually remove the `.angular` directory once after running this command.
|
||||
|
||||
### Enable Cache
|
||||
|
||||
```shell
|
||||
ng cache enable
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> You will need to delete the `.angular` cache and restart the dev server every time you want to sync local changes of Ionic.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
> [!NOTE]
|
||||
> Please confirm your current directory as `packages/angular/test` before proceeding with any of the following commands.
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of Angular we want to test. Typically these directories contain new `package.json` files, `angular.json` files, and more. If you have code that is specific to a particular version of Angular, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/ng14 as a reference
|
||||
./build.sh ng14
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.spec.ts` in `apps/ng14`, make sure you place the file in `apps/ng14/e2e/src/test.spec.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
### Testing Lazy Loaded Ionic Components
|
||||
|
||||
Tests for lazy loaded Ionic UI components should only be added under the `/lazy` route. This ensures the `IonicModule` is added.
|
||||
|
||||
### Testing Standalone Ionic Components
|
||||
|
||||
Tests for standalone Ionic UI components should only be added under the `/standalone` route. This allows for an isolated environment where the lazy loaded `IonicModule` is not initialized. The standalone components use Stencil's custom element bundle instead of the lazy loaded bundle. If `IonicModule` is initialized then the Stencil components will fall back to using the lazy loaded implementation instead of the custom elements bundle implementation.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of Angular, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of Angular that Ionic tests.
|
||||
2. Update the application by following the steps on https://update.angular.io/.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, `angular.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-core-angular` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
|
||||
Example:
|
||||
|
||||
In this example, we are going to add the Angular 14 test app.
|
||||
|
||||
1. Build the Angular 13 test app using `./build.sh ng13`.
|
||||
2. Navigate to `build/ng13`.
|
||||
3. Perform the upgrade steps on https://update.angular.io/. The "From" field should say "13.0" and the "To" field should say "14.0".
|
||||
|
||||
Note: You may encounter some other peer dependency issues not covered by the Angular Upgrade Guide. These peer dependency issues can be resolved manually by updating the installed version of each dependency.
|
||||
|
||||
4. Observe that the output of the Angular upgrade indicates that the following files were modified:
|
||||
|
||||
`angular.json`
|
||||
`package-lock.json`
|
||||
`package.json`
|
||||
`tsconfig.json`
|
||||
`src/app/form/form.component.ts`
|
||||
`src/app/modal-example/modal-example.component.ts`
|
||||
|
||||
5. Create a directory in `apps` named `ng14`.
|
||||
6. Copy the modified files to the `apps/ng14` directory.
|
||||
7. Open `./github/workflows/build.yml` and find the `test-angular-e2e` job.
|
||||
8. Find the `apps` field under `matrix`.
|
||||
9. Add "ng14" to the `apps` field.
|
||||
10. Open `./github/workflows/stencil-nightly.yml` and find the `test-angular-e2e` job.
|
||||
11. Repeat steps 8 and 9.
|
||||
12. Commit these changes and push.
|
||||
|
|
@ -760,7 +760,7 @@ To work around this, you should set an RTL class on the host of your component a
|
|||
<Host
|
||||
class={{
|
||||
'my-cmp-rtl': document.dir === 'rtl'
|
||||
})
|
||||
}}
|
||||
>
|
||||
...
|
||||
</Host>
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Ionic Core
|
||||
|
||||
The [@ionic/core](https://www.npmjs.com/package/@ionic/core) package contains the Web Components that make up the reusable UI building blocks of Ionic Framework. These components are designed to be used in traditional frontend view libraries/frameworks (such as React, Angular, or Vue), or on their own through traditional JavaScript in the browser.
|
||||
|
||||
## Contributing
|
||||
|
||||
See our [Contributing Guide](/docs/CONTRIBUTING.md).
|
||||
|
||||
## Testing
|
||||
|
||||
Refer to the [Core Testing documentation](./testing/README.md) for testing the Core package.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
|
||||
# Core Testing
|
||||
|
||||
## Directory
|
||||
|
||||
| Directory | Description |
|
||||
| --------------------------------------------- | --------------------------------------------------------------------------------------------- |
|
||||
| [Preview Changes](./preview-changes.md) | Steps on building core and previewing changes |
|
||||
| [Usage Instructions](./usage-instructions.md) | How to run tests and update screenshots |
|
||||
| [Best Practices](./best-practices.md) | Contains information on conventions to follow as well as pitfalls to avoid when writing tests |
|
||||
| [API](./api.md) | Documents the custom functionality that has been built on top of Playwright |
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# Preview Changes
|
||||
|
||||
## Build
|
||||
|
||||
### 1. Clone ionic
|
||||
|
||||
git clone https://github.com/ionic-team/ionic-framework.git
|
||||
cd ionic-framework
|
||||
|
||||
### 2. Run `npm install`
|
||||
|
||||
cd core
|
||||
npm install
|
||||
|
||||
Notice that `@ionic/core` lives in `core`.
|
||||
|
||||
### 3. Run `npm start`
|
||||
|
||||
Make sure you are inside the `core` directory.
|
||||
|
||||
npm start
|
||||
|
||||
With the `start` command, Ionic components will be built with [Stencil](https://stenciljs.com/), changes to source files are watched, a local http server will startup, and [http://localhost:3333/](http://localhost:3333/) will open in a browser.
|
||||
|
||||
### 4. Preview
|
||||
|
||||
Navigate to [http://localhost:3333/src/components/](http://localhost:3333/src/components/). Each component has small e2e apps found in the `test` directory, for example: [http://localhost:3333/src/components/button/test/basic](http://localhost:3333/src/components/button/test/basic)
|
||||
|
||||
As changes are made in an editor to source files, the e2e app will live-reload.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Ionic React Router
|
||||
|
||||
The [@ionic/react-router](https://www.npmjs.com/package/@ionic/react-router) package is the routing integration for [@ionic/react](https://www.npmjs.com/package/@ionic/react). It uses the [React Router](https://github.com/remix-run/react-router) library beneath the surface.
|
||||
|
||||
## Contributing
|
||||
|
||||
See our [Contributing Guide](/docs/CONTRIBUTING.md).
|
||||
|
||||
## Testing
|
||||
|
||||
Refer to the [React Router Testing documentation](./testing.md) for testing the React Router package.
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# React Router Testing
|
||||
|
||||
Ionic Framework supports multiple versions of React Router. As a result, we need to verify that Ionic works correctly with each of these React Router versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The React test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. Build the `@ionic/core`, `@ionic/react`, and `@ionic/react-router` projects using `npm run build`.
|
||||
2. [Build the React test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app.
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to wipe the build cache in `node_modules/.cache` and restart the dev server/re-build.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of React we want to test. Typically these directories contain new `package.json` files, `cypress.config.ts` files, and more. If you have code that is specific to a particular version of React, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/reactrouter5 as a reference
|
||||
./build.sh reactrouter5
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.e2e.ts` in `apps/reactrouter5`, make sure you place the file in `apps/react17/tests/e2e/test.e2e.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of React Router, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of React Router that Ionic tests.
|
||||
2. Update the application to the latest version of React Router.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-react-router-e2e` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Ionic React
|
||||
|
||||
The [@ionic/react](https://www.npmjs.com/package/@ionic/react) package builds on top of [@ionic/core](https://www.npmjs.com/package/@ionic/core) components.
|
||||
|
||||
## Contributing
|
||||
|
||||
See our [Contributing Guide](/docs/CONTRIBUTING.md).
|
||||
|
||||
## Testing
|
||||
|
||||
Refer to the [React Testing documentation](./testing.md) for testing the React package.
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# React Testing
|
||||
|
||||
Ionic Framework supports multiple versions of React. As a result, we need to verify that Ionic works correctly with each of these React versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The React test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. Build the `core`, `packages/react`, and `packages/react-router` directories using `npm run build`.
|
||||
2. [Build the React test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app.
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to wipe the build cache in `node_modules/.cache` and restart the dev server/re-build.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of React we want to test. Typically these directories contain new `package.json` files, `cypress.config.ts` files, and more. If you have code that is specific to a particular version of React, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/react17 as a reference
|
||||
./build.sh react17
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.e2e.ts` in `apps/react17`, make sure you place the file in `apps/react17/tests/e2e/test.e2e.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of React, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of React that Ionic tests.
|
||||
2. Update the application to the latest version of React.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-react-e2e` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
|
|
@ -0,0 +1,685 @@
|
|||
# Sass Guidelines
|
||||
|
||||
- [Definitions](#definitions)
|
||||
- [Scope](#scope)
|
||||
- [Historical Usage](#historical-usage)
|
||||
- [Current Usage](#current-usage)
|
||||
- [Recommended Usage](#recommended-usage)
|
||||
* [Comments](#comments)
|
||||
* [Variables](#variables)
|
||||
+ [✅ Global](#-global)
|
||||
+ [✅ Theming](#-theming)
|
||||
+ [✅ Reusable values](#-reusable-values)
|
||||
+ [✅ Media queries](#-media-queries)
|
||||
+ [✅ Dynamic calculations](#-dynamic-calculations)
|
||||
+ [🚫 Consistency](#-consistency)
|
||||
+ [🚫 Text Alignment](#-text-alignment)
|
||||
+ [🚫 Structural Changes](#-structural-changes)
|
||||
+ [🚫 Font Properties](#-font-properties)
|
||||
|
||||
## Definitions
|
||||
|
||||
**Sass:** An extension to CSS that reduces the repetition in CSS and allows developers to use shared functions, mixins and variables. [^1]
|
||||
|
||||
**Members:** Refers to variables, functions and mixins in Sass.
|
||||
|
||||
## Scope
|
||||
|
||||
Sass provides members that make it easier to reuse code throughout the Ionic Framework repository. Variables hold values that can be used by other stylesheets. Mixins define reusable blocks of styles that can be included in other selectors. Functions allow the manipulation of values and can perform calculations.
|
||||
|
||||
The purpose of this document is to identify the scenarios in which Sass variables should be used.
|
||||
|
||||
## Historical Usage
|
||||
|
||||
In Ionic Framework v1 through v3, the project was built with Sass variables that developers could change at runtime. While the default values were provided by Ionic Framework, anyone developing with it could override these values to rebuild the Ionic Framework CSS with their own values. [^2]
|
||||
|
||||
Due to this, Ionic Framework documented the Sass variables as part of the public API using `@prop` comments as early as [v2.0.0](https://github.com/ionic-team/ionic-framework/blob/v2.0.0/src/components/alert/alert.ios.scss):
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
/// @prop - Max width of the alert
|
||||
$alert-ios-max-width: 270px !default;
|
||||
|
||||
/// @prop - Border radius of the alert
|
||||
$alert-ios-border-radius: 13px !default;
|
||||
```
|
||||
|
||||
If a Sass variable was deprecated or hidden from the public API, the `@prop` comment would be removed, or it would never be added, as seen in [v3.9.2](https://github.com/ionic-team/ionic-framework/blob/v3.9.2/src/components/alert/alert.ios.scss#L18-L19):
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
// deprecated
|
||||
$alert-ios-head-padding: null !default;
|
||||
```
|
||||
|
||||
To ensure proper documentation of variables for customizing Ionic Framework, Sass variables were added for components even if they were not used multiple times within the same component or elsewhere:
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
/// @prop - Text color of the label for the checked radio alert
|
||||
$alert-ios-radio-label-text-color-checked: $alert-ios-button-text-color !default;
|
||||
|
||||
.alert-ios [aria-checked=true] .alert-radio-label {
|
||||
color: $alert-ios-radio-label-text-color-checked;
|
||||
}
|
||||
```
|
||||
|
||||
## Current Usage
|
||||
|
||||
The abundance of Sass variables currently in Ionic Framework is a result of their historical usage, being used to rebuild the CSS and customize Ionic Framework components.
|
||||
|
||||
The comments for Sass variables are also still visible today in [v7.7.0](https://github.com/ionic-team/ionic-framework/blob/v7.7.0/core/src/components/alert/alert.ios.vars.scss), even though they are no longer used by any documentation generators:
|
||||
|
||||
```scss
|
||||
// alert.ios.vars.scss
|
||||
|
||||
/// @prop - Max width of the alert
|
||||
$alert-ios-max-width: dynamic-font-clamp(1, 270px, 1.2) !default;
|
||||
|
||||
/// @prop - Border radius of the alert
|
||||
$alert-ios-border-radius: 13px !default;
|
||||
```
|
||||
|
||||
These comments aren't necessary when the naming describes its use thoroughly. The comments for the variables above do not need to be there, as it is fairly obvious what they are used for.
|
||||
|
||||
However, the comment for the following variable might be helpful in explaining where it is used because on first glance it reads like it could be used for a sub title inside of a title:
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.vars.scss
|
||||
|
||||
/// @prop - Font weight of the action sheet title when it has a sub title
|
||||
$action-sheet-ios-title-with-sub-title-font-weight: 600 !default;
|
||||
```
|
||||
|
||||
It could be argued though that the comment doesn't really help, as seeing the variable in use will explain its purpose the best. Additionally, this is an example of a variable that isn't necessary, given it is only used in one place, which is why it is so specific in the first place.
|
||||
|
||||
## Recommended Usage
|
||||
|
||||
There are two things that need to be outlined here: when we should use comments and when we should use variables. The sections below detail the recommended usage for each of these.
|
||||
|
||||
### Comments
|
||||
|
||||
We should update the comments for Sass variables in one of the following ways:
|
||||
|
||||
1. If we don't intend to ever publicly document the Sass variables again, we should update the comments to remove the syntax that was added for documentation generation:
|
||||
```diff
|
||||
// alert.ios.vars.scss
|
||||
|
||||
-/// @prop - Border radius of the alert
|
||||
+// Border radius of the alert
|
||||
$alert-ios-border-radius: 13px !default;
|
||||
```
|
||||
|
||||
2. If we don't find the comments to be helpful, and want to stick with keeping the variable names specific, we should remove the comments entirely:
|
||||
```diff
|
||||
// alert.ios.vars.scss
|
||||
|
||||
-/// @prop - Border radius of the alert
|
||||
$alert-ios-border-radius: 13px !default;
|
||||
```
|
||||
|
||||
3. If we find the comments to be helpful for certain variables or situations, like when there are math calculations involved, we should keep only the comments that are necessary to explain what is going on:
|
||||
```diff
|
||||
-/// @prop - Height of the alert button
|
||||
/**
|
||||
* We want the height of the button to
|
||||
* scale with the text so the next never runs
|
||||
* into the edge of the button. We change the height
|
||||
* instead of adding padding because we would need to offset
|
||||
* the height the padding and the border. Since the border uses
|
||||
* a hairline (<1px) width, this will cause subpixel rendering
|
||||
* differences across browsers.
|
||||
*/
|
||||
$alert-ios-button-height: dynamic-font-min(1, 44px) !default;
|
||||
```
|
||||
|
||||
### Variables
|
||||
|
||||
The table below outlines the recommended approach for when to use Sass variables. Each scenario links to a section that explains it in more detail.
|
||||
|
||||
| | Scenario |
|
||||
| ---| ---------------------------------------------------------------|
|
||||
| ✅ | [Global](#white_check_mark-global) |
|
||||
| ✅ | [Theming](#white_check_mark-theming) |
|
||||
| ✅ | [Reusable values](#white_check_mark-reusable-values) |
|
||||
| ✅ | [Media queries](#white_check_mark-media-queries) |
|
||||
| ✅ | [Dynamic calculations](#white_check_mark-dynamic-calculations) |
|
||||
| 🚫 | [Consistency](#no_entry_sign-consistency) |
|
||||
| 🚫 | [Text Alignment](#no_entry_sign-text-alignment) |
|
||||
| 🚫 | [Structural Changes](#no_entry_sign-structural-changes) |
|
||||
| 🚫 | [Font Properties](#no_entry_sign-font-properties) |
|
||||
|
||||
#### ✅ Global
|
||||
|
||||
Global variables that are used in multiple places include `font-family`, `z-index`, and `opacity`. These should continue to be set in variables as they affect multiple components that use them.
|
||||
|
||||
Example of global variables:
|
||||
|
||||
```scss
|
||||
// ionic.globals.scss
|
||||
|
||||
$font-family-base: var(--ion-font-family, inherit) !default;
|
||||
|
||||
$hairlines-width: .55px !default;
|
||||
|
||||
$placeholder-opacity: 0.6 !default;
|
||||
```
|
||||
|
||||
#### ✅ Theming
|
||||
|
||||
Storing colors and other design-related values makes it easy to update an entire theme by modifying a few variables.
|
||||
|
||||
Example of theme variables:
|
||||
|
||||
```scss
|
||||
// ionic.theme.default.scss
|
||||
|
||||
$background-color-value: #fff !default;
|
||||
$background-color-rgb-value: 255, 255, 255 !default;
|
||||
|
||||
$text-color-value: #000 !default;
|
||||
$text-color-rgb-value: 0, 0, 0 !default;
|
||||
|
||||
$background-color: var(--ion-background-color, $background-color-value) !default;
|
||||
$background-color-rgb: var(--ion-background-color-rgb, $background-color-rgb-value) !default;
|
||||
$text-color: var(--ion-text-color, $text-color-value) !default;
|
||||
$text-color-rgb: var(--ion-text-color-rgb, $text-color-rgb-value) !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// ionic.theme.default.ios.scss
|
||||
|
||||
$backdrop-ios-color: var(--ion-backdrop-color, #000) !default;
|
||||
$overlay-ios-background-color: var(--ion-overlay-background-color, var(--ion-color-step-100, #f9f9f9)) !default;
|
||||
```
|
||||
|
||||
#### ✅ Reusable values
|
||||
|
||||
Use variables for values that are repeated throughout stylesheets, such as spacing, `border-radius`, `font-size`, or any other value used in multiple places. A value should only be considered reusable if it is used more than once and related among the elements it is being applied to in some way. For instance, a value is not considered related if it changes a common property, such as border style. While many components use `border-style: solid`, it does not need to be stored unless these components will require updates with design changes. Currently, the border styles have consistently been set to `solid`, with the exception of `none` for a CSS reset.
|
||||
|
||||
Example of reusable values:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// alert.ios.vars.scss
|
||||
|
||||
/// @prop - Padding end of the alert head
|
||||
$alert-ios-head-padding-end: 16px !default;
|
||||
|
||||
/// @prop - Padding start of the alert head
|
||||
$alert-ios-head-padding-start: $alert-ios-head-padding-end !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
.alert-head {
|
||||
padding-top: 12px;
|
||||
padding-inline-end: $alert-ios-head-padding-end;
|
||||
padding-bottom: 7px;
|
||||
padding-inline-start: $alert-ios-head-padding-start;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr></tr>
|
||||
<tr>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// alert.ios.vars.scss
|
||||
|
||||
/// @prop - Padding top of the alert head
|
||||
$alert-ios-head-padding-top: 12px !default;
|
||||
|
||||
/// @prop - Padding bottom of the alert head
|
||||
$alert-ios-head-padding-bottom: 7px !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
.alert-head {
|
||||
padding-top: $alert-ios-head-padding-top;
|
||||
padding-bottom: $alert-ios-head-padding-bottom;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
If a value is shared among multiple components, it should be made into a [global variable](#white_check_mark-global) instead of importing the variable from a specific component. For example, variables that are shared between list components (item, item divider, list header) should be defined in a global theme file:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// ionic.theme.default.md.scss
|
||||
|
||||
$global-md-item-padding-end: 16px;
|
||||
$global-md-item-padding-start: $global-md-item-padding-end;
|
||||
```
|
||||
|
||||
```scss
|
||||
// item.md.vars.scss
|
||||
|
||||
@import "../../themes/ionic.globals.md";
|
||||
|
||||
/// @prop - Padding end for the item content
|
||||
$item-md-padding-end: $global-md-item-padding-end !default;
|
||||
|
||||
/// @prop - Padding start for the item content
|
||||
$item-md-padding-start: $global-md-item-padding-start !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// item-divider.md.vars.scss
|
||||
|
||||
@import "../../themes/ionic.globals.md";
|
||||
|
||||
/// @prop - Padding start for the divider
|
||||
$item-divider-md-padding-start: $global-md-item-padding-start !default;
|
||||
|
||||
/// @prop - Padding end for the divider
|
||||
$item-divider-md-padding-end: $global-md-item-padding-end !default;
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr></tr>
|
||||
<tr>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// item.md.vars.scss
|
||||
|
||||
@import "../../themes/ionic.globals.md";
|
||||
|
||||
/// @prop - Padding end for the item content
|
||||
$item-md-padding-end: 16px !default;
|
||||
|
||||
/// @prop - Padding start for the item content
|
||||
$item-md-padding-start: 16px !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// item-divider.md.vars.scss
|
||||
|
||||
@import "../../themes/ionic.globals.md";
|
||||
@import "../item/item.md.vars";
|
||||
|
||||
/// @prop - Padding start for the divider
|
||||
$item-divider-md-padding-start: $item-md-padding-start !default;
|
||||
|
||||
/// @prop - Padding end for the divider
|
||||
$item-divider-md-padding-end: $item-md-padding-end !default;
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
> [!TIP]
|
||||
> The names of the global variables are just an example. We do not currently have a naming convention for global variables.
|
||||
|
||||
#### ✅ Media queries
|
||||
|
||||
Define breakpoints for responsive design to allow easy adjustments as needed.
|
||||
|
||||
Example of breakpoints used by media queries:
|
||||
|
||||
```scss
|
||||
// ionic.globals.scss
|
||||
|
||||
// The minimum dimensions at which your layout will change,
|
||||
// adapting to different screen sizes, for use in media queries
|
||||
$screen-breakpoints: (
|
||||
xs: 0,
|
||||
sm: 576px,
|
||||
md: 768px,
|
||||
lg: 992px,
|
||||
xl: 1200px
|
||||
) !default;
|
||||
```
|
||||
|
||||
#### ✅ Dynamic calculations
|
||||
|
||||
Variables can be useful for dynamic calculations, such as storing a base font size in a variable and then using it in calculations for other font sizes or spacing values. Variables should not be used for storing a function call, even if the function itself has dynamic calculations.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// chip.vars.scss
|
||||
|
||||
/// @prop - Unitless font size of the chip before scaling
|
||||
$chip-base-font-size: 14;
|
||||
|
||||
/// @prop - Font size of the chip in rem before scaling
|
||||
$chip-base-font-size-rem: #{math.div($chip-base-font-size, 16)}rem;
|
||||
|
||||
/// @prop - Size of an icon within a chip (in em to scale as the font size of the chip scales)
|
||||
$chip-icon-size: math.div(20em, $chip-base-font-size);
|
||||
|
||||
/// @prop - Size of an avatar within a chip (in em to scale as the font size of the chip scales)
|
||||
$chip-avatar-size: math.div(24em, $chip-base-font-size);
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr></tr>
|
||||
<tr>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// alert.vars.scss
|
||||
|
||||
/// @prop - Font size of the alert button
|
||||
$alert-button-font-size: dynamic-font(14px) !default;
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### 🚫 Consistency
|
||||
|
||||
While we usually aim for consistency across different modes, this isn't always necessary when dealing with Sass variables. If certain styles are present in one mode but absent in another, there's no need to include a Sass variable for the mode lacking those styles.
|
||||
|
||||
For example, the color of the label changes when focused in `md` mode. However, in `ios`, the label does not receive different styling when focused, therefore it does not require the same styles or a Sass variable defined:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// label.md.vars.scss
|
||||
|
||||
/// @prop - Text color of the stacked/floating label when it is focused
|
||||
$label-md-text-color-focused: ion-color(primary, base) !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// label.md.scss
|
||||
|
||||
:host-context(.ion-focused).label-stacked:not(.ion-color),
|
||||
:host-context(.ion-focused).label-floating:not(.ion-color),
|
||||
:host-context(.item-has-focus).label-stacked:not(.ion-color),
|
||||
:host-context(.item-has-focus).label-floating:not(.ion-color) {
|
||||
color: $label-md-text-color-focused;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr></tr>
|
||||
<tr>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// label.ios.vars.scss
|
||||
|
||||
/// @prop - Text color of the stacked/floating label when it is focused
|
||||
$label-ios-text-color-focused: null !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// label.ios.scss
|
||||
|
||||
:host-context(.ion-focused).label-stacked:not(.ion-color),
|
||||
:host-context(.ion-focused).label-floating:not(.ion-color),
|
||||
:host-context(.item-has-focus).label-stacked:not(.ion-color),
|
||||
:host-context(.item-has-focus).label-floating:not(.ion-color) {
|
||||
color: $label-ios-text-color-focused;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### 🚫 Text Alignment
|
||||
|
||||
A text alignment property should not be stored in a Sass variable, even if it is used in multiple places. This is because the alignment may be tied to a specific design, and the design may change, causing them to become disconnected.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.scss
|
||||
|
||||
:host {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.action-sheet-title {
|
||||
text-align: center;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.vars.scss
|
||||
|
||||
/// @prop - Text align of the action sheet
|
||||
$action-sheet-ios-text-align: center !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.scss
|
||||
|
||||
:host {
|
||||
text-align: $action-sheet-ios-text-align;
|
||||
}
|
||||
|
||||
.action-sheet-title {
|
||||
text-align: $action-sheet-ios-text-align;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
#### 🚫 Structural Changes
|
||||
|
||||
Variables should not be used when they are structural changes of an element. This includes `display` properties, `flex` properties, `grid` properties, and more.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
.alert-button-group {
|
||||
flex-wrap: wrap;
|
||||
}
|
||||
|
||||
.alert-button {
|
||||
flex: 1 1 auto;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr></tr>
|
||||
<tr>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
|
||||
```scss
|
||||
// alert.ios.vars.scss
|
||||
|
||||
/// @prop - Flex wrap of the alert button group
|
||||
$alert-ios-button-group-flex-wrap: wrap !default;
|
||||
|
||||
/// @prop - Flex of the alert button
|
||||
$alert-ios-button-flex: 1 1 auto !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// alert.ios.scss
|
||||
|
||||
.alert-button-group {
|
||||
flex-wrap: $alert-ios-button-group-flex-wrap;
|
||||
}
|
||||
|
||||
.alert-button {
|
||||
flex: $alert-ios-button-flex;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
#### 🚫 Font Properties
|
||||
|
||||
We shouldn't use variables for changing things such as `font-size` or `font-weight`, as these are not changed based on a theme and do not need to be updated globally. When updating the `font-size` and `font-weight` for these elements, it will always be done on a case-by-case basis:
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Do ✅</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.scss
|
||||
|
||||
.action-sheet-title {
|
||||
font-size: dynamic-font-min(1, 13px);
|
||||
font-weight: 400;
|
||||
}
|
||||
|
||||
.action-sheet-sub-title {
|
||||
font-size: dynamic-font-min(1, 13px);
|
||||
font-weight: 400;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr></tr>
|
||||
<tr>
|
||||
<th>Don't :x:</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top">
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.vars.scss
|
||||
|
||||
/// @prop - Font size of the action sheet title
|
||||
$action-sheet-ios-title-font-size: dynamic-font-min(1, 13px) !default;
|
||||
|
||||
/// @prop - Font weight of the action sheet title
|
||||
$action-sheet-ios-title-font-weight: 400 !default;
|
||||
|
||||
/// @prop - Font size of the action sheet sub title
|
||||
$action-sheet-ios-sub-title-font-size: dynamic-font-min(1, 13px) !default;
|
||||
```
|
||||
|
||||
```scss
|
||||
// action-sheet.ios.scss
|
||||
|
||||
.action-sheet-title {
|
||||
font-size: $action-sheet-ios-title-font-size;
|
||||
font-weight: $action-sheet-ios-title-font-weight;
|
||||
}
|
||||
|
||||
.action-sheet-sub-title {
|
||||
font-size: $action-sheet-ios-sub-title-font-size;
|
||||
font-weight: $action-sheet-ios-title-font-weight;
|
||||
}
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
[^1]: Sass Documentation, https://sass-lang.com/documentation/
|
||||
|
||||
[^2]: Ionic Framework v3 Documentation - Theming - Overriding Ionic Variables, https://ionicframework.com/docs/v3/theming/overriding-ionic-variables/
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Ionic Vue Router
|
||||
|
||||
The [@ionic/vue-router](https://www.npmjs.com/package/@ionic/vue-router) package is the routing integration for [@ionic/vue](https://www.npmjs.com/package/@ionic/vue). It uses the [Vue Router](https://router.vuejs.org/) library beneath the surface.
|
||||
|
||||
## Contributing
|
||||
|
||||
See our [Contributing Guide](/docs/CONTRIBUTING.md).
|
||||
|
||||
## Testing
|
||||
|
||||
Refer to the [Vue Router Testing documentation](./testing.md) for testing the Vue Router package.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Vue Router Testing
|
||||
|
||||
## Tests
|
||||
|
||||
* Tests are found in the `__tests__` directory and use Jest.
|
||||
* Tests can be run using `npm run test.spec`
|
||||
* Bug fix and feature PRs should have new tests verifying the PR functionality.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Ionic Vue
|
||||
|
||||
The [@ionic/vue](https://www.npmjs.com/package/@ionic/vue) package builds on top of [@ionic/core](https://www.npmjs.com/package/@ionic/core) components.
|
||||
|
||||
## Contributing
|
||||
|
||||
See our [Contributing Guide](/docs/CONTRIBUTING.md).
|
||||
|
||||
## Testing
|
||||
|
||||
Refer to the [Vue Testing documentation](./testing.md) for testing the Vue package.
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
# Vue Testing
|
||||
|
||||
Ionic Framework supports multiple versions of Vue. As a result, we need to verify that Ionic works correctly with each of these Vue versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The Vue test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. [Build](../README.md#building) the `core`, `packages/vue`, and `packages/vue-router` projects using `npm run build`.
|
||||
2. [Build the Vue test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app directory (e.g. `packages/vue/test/build/vue3`).
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to wipe the build cache in `node_modules/.cache` and restart the dev server/re-build.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
> [!NOTE]
|
||||
> Please confirm your current directory as `packages/vue/test` before proceeding with any of the following commands.
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of Vue we want to test. Typically these directories contain new `package.json` files, `jest.config.js` files, and more. If you have code that is specific to a particular version of Vue, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/vue3 as a reference
|
||||
./build.sh vue3
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.e2e.ts` in `apps/vue3`, make sure you place the file in `apps/vue3/tests/e2e/test.e2e.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of Vue, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of Vue that Ionic tests.
|
||||
2. Update the application to the latest version of Vue.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-core-vue` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
|
|
@ -1,118 +1,3 @@
|
|||
# Angular E2E Test Apps
|
||||
|
||||
Ionic Framework supports multiple versions of Angular. As a result, we need to verify that Ionic works correctly with each of these Angular versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The Angular test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. Build the `core` and `packages/angular` directories using `npm run build`.
|
||||
2. [Build the Angular test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app directory (e.g. `packages/angular/test/build/ng14`).
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to [wipe or disable the application cache](#application-cache).
|
||||
|
||||
## Application Cache
|
||||
|
||||
Angular CLI creates a cache of several files on disk by default in the `.angular` directory. This decreases the time taken to build the test application. However, the cache makes it difficult to quickly sync and check local changes of Ionic. As a result, the `.angular` cache is disabled by default in the test app projects.
|
||||
|
||||
See https://angular.io/cli/cache for more information.
|
||||
|
||||
### Disable Cache
|
||||
|
||||
```shell
|
||||
ng cache disable
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> You may need to manually remove the `.angular` directory once after running this command.
|
||||
|
||||
### Enable Cache
|
||||
|
||||
```shell
|
||||
ng cache enable
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> You will need to delete the `.angular` cache and restart the dev server every time you want to sync local changes of Ionic.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
> [!NOTE]
|
||||
> Please confirm your current directory as `packages/angular/test` before proceeding with any of the following commands.
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of Angular we want to test. Typically these directories contain new `package.json` files, `angular.json` files, and more. If you have code that is specific to a particular version of Angular, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/ng14 as a reference
|
||||
./build.sh ng14
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.spec.ts` in `apps/ng14`, make sure you place the file in `apps/ng14/e2e/src/test.spec.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
### Testing Lazy Loaded Ionic Components
|
||||
|
||||
Tests for lazy loaded Ionic UI components should only be added under the `/lazy` route. This ensures the `IonicModule` is added.
|
||||
|
||||
### Testing Standalone Ionic Components
|
||||
|
||||
Tests for standalone Ionic UI components should only be added under the `/standalone` route. This allows for an isolated environment where the lazy loaded `IonicModule` is not initialized. The standalone components use Stencil's custom element bundle instead of the lazy loaded bundle. If `IonicModule` is initialized then the Stencil components will fall back to using the lazy loaded implementation instead of the custom elements bundle implementation.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of Angular, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of Angular that Ionic tests.
|
||||
2. Update the application by following the steps on https://update.angular.io/.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, `angular.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-core-angular` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
|
||||
Example:
|
||||
|
||||
In this example, we are going to add the Angular 14 test app.
|
||||
|
||||
1. Build the Angular 13 test app using `./build.sh ng13`.
|
||||
2. Navigate to `build/ng13`.
|
||||
3. Perform the upgrade steps on https://update.angular.io/. The "From" field should say "13.0" and the "To" field should say "14.0".
|
||||
|
||||
Note: You may encounter some other peer dependency issues not covered by the Angular Upgrade Guide. These peer dependency issues can be resolved manually by updating the installed version of each dependency.
|
||||
|
||||
4. Observe that the output of the Angular upgrade indicates that the following files were modified:
|
||||
|
||||
`angular.json`
|
||||
`package-lock.json`
|
||||
`package.json`
|
||||
`tsconfig.json`
|
||||
`src/app/form/form.component.ts`
|
||||
`src/app/modal-example/modal-example.component.ts`
|
||||
|
||||
5. Create a directory in `apps` named `ng14`.
|
||||
6. Copy the modified files to the `apps/ng14` directory.
|
||||
7. Open `./github/workflows/build.yml` and find the `test-angular-e2e` job.
|
||||
8. Find the `apps` field under `matrix`.
|
||||
9. Add "ng14" to the `apps` field.
|
||||
10. Open `./github/workflows/stencil-nightly.yml` and find the `test-angular-e2e` job.
|
||||
11. Repeat steps 8 and 9.
|
||||
12. Commit these changes and push.
|
||||
Refer to the [Angular Testing documentation](/docs/angular/testing.md) in order to build and run the test app.
|
||||
|
|
|
|||
|
|
@ -1,2 +1,2 @@
|
|||
## @ionic/react-router (beta)
|
||||
# @ionic/react-router
|
||||
|
||||
|
|
|
|||
|
|
@ -1,55 +1,3 @@
|
|||
# React Router E2E Test Apps
|
||||
|
||||
Ionic Framework supports multiple versions of React Router. As a result, we need to verify that Ionic works correctly with each of these React Router versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The React test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. Build the `@ionic/core`, `@ionic/react`, and `@ionic/react-router` projects using `npm run build`.
|
||||
2. [Build the React test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app.
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to wipe the build cache in `node_modules/.cache` and restart the dev server/re-build.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of React we want to test. Typically these directories contain new `package.json` files, `cypress.config.ts` files, and more. If you have code that is specific to a particular version of React, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/reactrouter5 as a reference
|
||||
./build.sh reactrouter5
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.e2e.ts` in `apps/reactrouter5`, make sure you place the file in `apps/react17/tests/e2e/test.e2e.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of React Router, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of React Router that Ionic tests.
|
||||
2. Update the application to the latest version of React Router.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-react-router-e2e` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
Refer to the [React Router Testing documentation](/docs/react-router/testing.md) in order to build and run the test app.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## @ionic/react
|
||||
# @ionic/react
|
||||
|
||||
These are React specific building blocks on top of [@ionic/core](https://www.npmjs.com/package/@ionic/core) components/services.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,55 +1,3 @@
|
|||
# React E2E Test Apps
|
||||
|
||||
Ionic Framework supports multiple versions of React. As a result, we need to verify that Ionic works correctly with each of these React versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The React test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. Build the `core`, `packages/react`, and `packages/react-router` directories using `npm run build`.
|
||||
2. [Build the React test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app.
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to wipe the build cache in `node_modules/.cache` and restart the dev server/re-build.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of React we want to test. Typically these directories contain new `package.json` files, `cypress.config.ts` files, and more. If you have code that is specific to a particular version of React, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/react17 as a reference
|
||||
./build.sh react17
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.e2e.ts` in `apps/react17`, make sure you place the file in `apps/react17/tests/e2e/test.e2e.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of React, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of React that Ionic tests.
|
||||
2. Update the application to the latest version of React.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-react-e2e` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
Refer to the [React Testing documentation](/docs/react/testing.md) in order to build and run the test app.
|
||||
|
|
|
|||
|
|
@ -1,47 +1,3 @@
|
|||
# React Test App
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Setup
|
||||
|
||||
Make sure you are using the latest versions of node and npm. If you do not have these, [download the installer](https://nodejs.org/) for the LTS version of Node.js. This is the best way to also [install npm](https://blog.npmjs.org/post/85484771375/how-to-install-npm#_=_).
|
||||
|
||||
### Building Dependencies
|
||||
|
||||
Navigate to the `core`, `packages/react` and `packages/react-router` directories and build each of them:
|
||||
|
||||
```bash
|
||||
npm i
|
||||
npm run build
|
||||
```
|
||||
|
||||
Then, install dependencies from this directory for this test app:
|
||||
|
||||
```
|
||||
npm i
|
||||
```
|
||||
|
||||
### Syncing Changes
|
||||
|
||||
When making changes to the React package, run the following from this directory to sync the changes:
|
||||
|
||||
```bash
|
||||
npm run sync
|
||||
```
|
||||
|
||||
### Previewing App
|
||||
|
||||
To preview this app locally, run the following from this directory:
|
||||
|
||||
```bash
|
||||
npm start
|
||||
```
|
||||
|
||||
### Running Tests
|
||||
|
||||
To run the e2e tests, run the following from this directory:
|
||||
|
||||
```
|
||||
npm run build
|
||||
npm run e2e
|
||||
```
|
||||
Refer to the [React Testing documentation](/docs/react/testing.md) in order to build and run the test app.
|
||||
|
|
|
|||
|
|
@ -1,58 +1,3 @@
|
|||
# Vue E2E Test Apps
|
||||
|
||||
Ionic Framework supports multiple versions of Vue. As a result, we need to verify that Ionic works correctly with each of these Vue versions.
|
||||
|
||||
## Syncing Local Changes
|
||||
|
||||
The Vue test app supports syncing your locally built changes for validation.
|
||||
|
||||
1. [Build](../README.md#building) the `core`, `packages/vue`, and `packages/vue-router` projects using `npm run build`.
|
||||
2. [Build the Vue test app](#test-app-build-structure).
|
||||
3. Navigate to the built test app directory (e.g. `packages/vue/test/build/vue3`).
|
||||
4. Install dependencies using `npm install`.
|
||||
5. Sync your local changes using `npm run sync`.
|
||||
|
||||
From here you can either build the application or start a local dev server. When re-syncing changes, you will need to wipe the build cache in `node_modules/.cache` and restart the dev server/re-build.
|
||||
|
||||
## Test App Build Structure
|
||||
|
||||
> [!NOTE]
|
||||
> Please confirm your current directory as `packages/vue/test` before proceeding with any of the following commands.
|
||||
|
||||
Unlike other test applications, these test apps are broken up into multiple directories. These directories are then combined to create a single application. This allows us to share common application code, tests, etc so that each app is being tested the same way. Below details the different pieces that help create a single test application.
|
||||
|
||||
**apps** - This directory contains partial applications for each version of Vue we want to test. Typically these directories contain new `package.json` files, `jest.config.js` files, and more. If you have code that is specific to a particular version of Vue, put it in this directory.
|
||||
|
||||
**base** - This directory contains the base application that each test app will use. This is where tests, application logic, and more live. If you have code that needs to be run on every test app, put it in this directory.
|
||||
|
||||
**build** - When the `apps` and `base` directories are merged, the final result is put in this directory. The `build` directory should never be committed to git.
|
||||
|
||||
**build.sh** - This is the script that merges the `apps` and `base` directories and places the built application in the `build` directory.
|
||||
|
||||
Usage:
|
||||
|
||||
```shell
|
||||
# Build a test app using apps/vue3 as a reference
|
||||
./build.sh vue3
|
||||
```
|
||||
|
||||
## How to modify test apps
|
||||
|
||||
To add new tests, components, or pages, modify the `base` project. This ensures that tests are run for every tested version.
|
||||
|
||||
If you want to add a version-specific change, add the change inside of the appropriate projects in `apps`. Be sure to replicate the directory structure. For example, if you are adding a new E2E test file called `test.e2e.ts` in `apps/vue3`, make sure you place the file in `apps/vue3/tests/e2e/test.e2e.ts`.
|
||||
|
||||
### Version-specific tests
|
||||
|
||||
If you need to add E2E tests that are only run on a specific version of the JS Framework, replicate the `VersionTest` component on each partial application. This ensures that tests for framework version X do not get run for framework version Y.
|
||||
|
||||
## Adding New Test Apps
|
||||
|
||||
As we add support for new versions of Vue, we will also need to update this directory to test against new applications. The following steps can serve as a guide for adding new apps:
|
||||
|
||||
1. Navigate to the built app for the most recent version of Vue that Ionic tests.
|
||||
2. Update the application to the latest version of Vue.
|
||||
3. Make note of any files that changed during the upgrade (`package.json`, `package-lock.json`, etc).
|
||||
4. Copy the changed files to a new directory in `apps`.
|
||||
5. Add a new entry to the matrix for `test-core-vue` in `./github/workflows/build.yml`. This will allow the new test app to run against all PRs.
|
||||
6. Commit these changes and push.
|
||||
Refer to the [Vue Testing documentation](/docs/vue/testing.md) in order to build and run the test app.
|
||||
|
|
|
|||
Loading…
Reference in New Issue