Ionic Documentation Source

repository·main·Indexed 20 days ago

https://github.com/ionic-team/ionic-docs

Source code and content for the official Ionic documentation website, built with the Docusaurus framework. This repository includes the documentation structure, global and page-specific components, styling architecture, and the Playground system for rendering framework-specific demo previews via StackBlitz.

Tokens
1.5M
Snippets
3.8K
Records
3.9K
Agent score
70%

What's inside ionic-docs

  1. Understand the structure of the Styles folder

    main

    The src/styles directory contains the global styling architecture for the documentation site. It is organized into two main parts:

    1. Global Styles: A global style file that is integrated into the theme via the docusaurus.config.js configuration.
    2. Components Folder: Contains styles specifically for theme components. This approach is used to style components directly instead of using the 'swizzling' process (which involves ejecting component code into your local project).

    Note on CSS Specificity: Because theme styles cannot be easily overridden in the current setup, selectors use the base __docusaurus tag to increase CSS specificity, ensuring these styles take precedence.

  2. Configure the Ionic CLI project and global settings

    main

    The Ionic CLI uses JSON files for configuration:

    • Global Configuration: Stored at ~/.ionic/config.json.
    • Project Configuration: Stored in ionic.config.json at the project's root directory.

    You can manage these values using the ionic config get and ionic config set commands.

    {
      "name": "My App",
      "type": "angular",
      "id": "abc123",
      "integrations": {
        "cordova": { ... }
      },
      "hooks": {
        "build:before": "./scripts/build-before.js"
      }
    }
  3. How versioning works for docs, components, and assets

    main

    The /docs folder is the source of truth for markdown files. When using the Docusaurus versioning script, any files located within the /docs directory (including subdirectories like _components/) are copied to versioned_docs/version-{X}/ to ensure that version-specific content, components, and assets are preserved for that specific version.

    To manage assets and components across versions, follow these placement rules:

    • Version-specific content: Place in /docs/ (e.g., docs/layout/_components/ for components specific to the layout section of a specific version).
    • Shared components: Place in src/components/ to make them available across all versions.
    • Shared assets/images: Place in static/ to ensure they are served globally across all versions.
  4. Override variables for light and dark themes

    main

    To provide theme-specific values for CSS variables, target the html[data-theme] attribute selector. This allows you to change component appearance based on the user's active theme.

    /* Light theme overrides */
    html[data-theme='light'] {
      --ifm-menu-color-background-active: red;
    }
    
    /* Dark theme overrides */
    html[data-theme='dark'] {
      --ifm-menu-color-background-active: blue;
    }
  5. How to override the Docusaurus theme

    main

    The src/theme folder is used to override the base Docusaurus theme (specifically @docusaurus/theme-classic).

    Best Practices for Swizzling

    When you need to customize components, follow these guidelines to minimize maintenance overhead during future version updates:

    1. Avoid Swizzling if possible: Only swizzle components when absolutely necessary.
    2. Prefer Shallow Swizzling: If you can achieve your goal by using the @theme-original alias to shallow swizzle a component, prioritize this method over a full swizzle.
    3. Maintainability:
      • Add all swizzled components to your .prettierignore file.
      • Mark all code updates/changes with comments to facilitate easier version upgrades.
    4. Styling Constraints:
      • Do NOT edit the styles files for components that have been 'unsafely swizzled'.
      • DO perform all styling via component partials.
  6. Initialize a multi-app project

    main

    If you are working in a monorepo or an unconventional repository structure, use the --multi-app flag to initialize your project as a multi-app project.

    Once a project is initialized as a multi-app project at the root, you can navigate into individual app directories and run ionic init again within those directories to initialize them as separate apps within the same project structure.

    $ ionic init --multi-app
  7. Use ion-menu-toggle to control menu visibility

    main

    The ion-menu-toggle component is used to automatically close the menu when its child elements (like an ion-button or ion-item) are interacted with. This is useful for providing a way to dismiss the menu from within the menu content itself.

    <ion-menu type="overlay" content-id="main-content">
      <ion-content>
        <ion-menu-toggle>
          <ion-button>Click to close the menu</ion-button>
        </ion-menu-toggle>
      </ion-content>
    </ion-menu>