Ionic Action Sheet : Une guide complet pour 2026

Vous êtes probablement dans l'une ou l'autre des situations actuellement. Soit vous avez besoin d'une façon propre pour afficher quelques actions contextuelles sans encombrer votre écran avec des boutons supplémentaires, soit vous avez déjà déployé un feuillet d'action ionic et découvert que la version de démonstration facile n'est pas la même chose qu'une mise en œuvre prête à la production.

Cette lacune compte. Un feuillet d'action semble simple, mais il se situe à l'intersection du design d'interaction, des API de framework, du comportement de plateforme, de l'accessibilité et de la maintenance après la mise en production. Si vous ne traitez que cela comme un popup avec des boutons, vous manquerez les parties qui cassent généralement tard en QA.

Table des matières

• Introduction au feuillet d'action ionic
  • Pourquoi les équipes continuent d'y avoir recours
• Comprendre le contrôleur de feuillet d'action et API
  • Pourquoi le API est dirigé par un contrôleur
  • Les options qui comptent vraiment
  • La fermeture fait partie du contrat
• Exemples d'implémentation pour Angular, React et Vue
  • Exemple Angular
  • Exemple React
  • Exemple Vue
• Personnalisation et style avec CSS
  • Commencez par cssClass avant les surcharges globales
  • Utilisez les propriétés personnalisées pour un thème large
  • Utilisez les parties d'ombre lorsque vous avez besoin de précision
• Sujets avancés et considérations de plateforme
  • Composant web ou plugin natif
  • Mode de plateforme et détails d'accessibilité
• Pièges de dépannage et corrections de l'interface utilisateur en direct
  • Les bogues qui apparaissent après que le démo fonctionne
  • A solution pratique pour la zone de sécurité
  • Pourquoi les mises à jour en temps réel sont importantes pour les défauts d'interface utilisateur

Introduction à la feuille d'action Ionique

La feuille d'action Ionique est l'outil approprié lorsque l'utilisateur doit effectuer une petite et focalisée choix lié au contexte actuel. Supprimer un brouillon. Remplacer une photo de profil. Enregistrer, partager ou archiver un document. Ces actions sont importantes, mais elles ne méritent pas d'occuper un espace permanent dans la disposition principale.

En Ionique, le modèle a resté cohérent pendant longtemps. Les applications Ionique anciennes utilisaient le $ionicActionSheet service, que TutorialsPoint décrit comme une fenêtre qui s'ouvre en glissant depuis le bas de l'écran et qui est affichée en injectant le service et en appelant show() dans le contrôleur. Les applications modernes utilisent ion-action-sheet, mais le modèle d'interaction est toujours reconnaissable, ce qui fait que le composant est l'un des exemples les plus clairs d'Ionique qui préserve les modèles d'interface utilisateur mobiles à travers les générations de frameworks dans la synthèse de la documentation de la feuille d'action Ionique 1 de TutorialsPoint.

Cette continuité est utile dans les projets réels. Cela signifie que le composant n'est pas une abstraction tendance qui a changé à chaque mise à jour. C'est un modèle mobile stable qui se mappent bien aux menus d'options iOS et Android, et il se sent toujours naturel dans les projets Angular, React et Vue.

Pourquoi les équipes continuent de s'y référer

Une feuille d'action fonctionne bien lorsque l'utilisateur comprend déjà le contexte et n'a besoin que d'une liste compacte de prochaines étapes. Elle fonctionne mal lorsque l'utilisateur a besoin d'une explication, d'une validation ou de plusieurs champs de formulaire.

Une règle simple aide :

• Utilisez une feuille d'actions pour les menus de décision courts liés à un élément spécifique.
• Utilisez un avertissement lorsque vous avez besoin de confirmation avec des options minimales.
• Utilisez un modèle lorsque l'utilisateur a besoin de plus de contenu, d'entrées ou de défilement.

Règle pratique : Si les étiquettes de bouton ne peuvent pas se tenir seules sans un paragraphe de texte supplémentaire, n'imposez pas l'interaction dans une feuille d'actions.

Dans les applications hybrides, ce modèle s'adapte également parfaitement au modèle web-natif. L'interface utilisateur est simple au point de pouvoir être rendue dans la couche web, tout en ressentant la nativité sur les appareils tactiles. Si votre équipe construit sur Capacitor et souhaite une représentation plus claire de cette frontière, ce détail de comment Capacitor relie le web et le natif code vaut la peine de le garder à l'esprit pendant que vous décidez où la feuille d'actions devrait vivre.

Comprendre le Contrôleur de la Feuille d'Action et API

La feuille d'action devient facile à raisonner une fois que vous arrêtez de la considérer comme simplement un autre composant inline. Elle se comporte plus comme un surcouche temporaire avec un cycle de vie. Vous la créez, vous la présentez, vous attendez l'utilisateur, et puis vous gérez le résultat après la fermeture.

Pourquoi le API est piloté par un Contrôleur

En travaux quotidiens d'Ionic, l'approche basée sur les contrôleurs est généralement la meilleure option car la feuille d'action est éphémère. Vous ne voulez pas avoir une grande partie de la mise en page de votre page pour un menu qui ne s'affiche que après un clic sur un icône de débordement.

Les documents officiels d'Ionic définissent la Feuille d'Action comme un dialogue modal qui nécessite la fermeture de l'utilisateur, et ils accordent beaucoup d'importance aux méthodes de cycle de vie de la fermeture, telles que onDidDismiss pour la logique de sélection postérieure dans les documents d'Ionic sur la Feuille d'Action API. Cette conception vous indique comment structurer votre code. Présentez d'abord. Réagissez ensuite à la fermeture. N'attachez pas de logique critique aux hypothèses sur le timing.

Les options qui comptent vraiment

La plupart des équipes n'ont besoin que d'une petite partie de la API, mais elles doivent l'utiliser correctement.

La configuration du bouton est souvent le point où les erreurs se produisent. Un bouton typique peut inclure :

• text __CAPGO_KEEP_0__ pour l'étiquette visible.
• icon __CAPGO_KEEP_1__ si vous souhaitez une indication visuelle.
• handler __CAPGO_KEEP_2__ pour la logique de rappel immédiate.
• role __CAPGO_KEEP_3__ pour le comportement sémantique et le style de la plateforme.

role __CAPGO_KEEP_4__ n'est pas décoratif. Utilisez __CAPGO_KEEP_5__ destructive __CAPGO_KEEP_6__ pour les actions dangereuses comme la suppression. Utilisez __CAPGO_KEEP_7__ cancel __CAPGO_KEEP_8__ pour le chemin d'échappement. Ces rôles affectent la présentation des choix dans la fenêtre d'action et la façon dont les utilisateurs lisent la liste sous pression.

Les actions dangereuses appartiennent aux bords du jeu de choix, et non mélangées aux actions neutres avec le même poids visuel.

La fermeture fait partie du contrat

Un bug courant se présente ainsi : un développeur ouvre une fenêtre d'action, suppose que le résultat du gestionnaire est suffisant, puis déclenche ensuite la navigation ou les mises à jour d'état avant que l'overlay n'ait complètement disparu. Cela peut produire des transitions floues, un état périmé ou des conditions de course dans les tests.

Utilisez le cycle de vie intentionnellement :

1. Créez la feuille.
2. await present().
3. await onDidDismiss().
4. Lisez le rôle ou les données retournés.
5. Déclenchez la prochaine action.

Ce modèle est ennuyeux, et c'est pourquoi il fonctionne.

Voici un exemple en style Angular simple de la forme :

const sheet = await this.actionSheetController.create({
  header: 'Photo options',
  buttons: [
    {
      text: 'Take Photo',
      icon: 'camera',
      handler: () => {
        console.log('take photo');
      }
    },
    {
      text: 'Delete Photo',
      role: 'destructive',
      icon: 'trash'
    },
    {
      text: 'Cancel',
      role: 'cancel'
    }
  ]
});

await sheet.present();

const result = await sheet.onDidDismiss();
console.log('dismissed with role:', result.role);

Si vous vous souvenez seulement d'une chose du API, rappellez-vous ceci : une fenêtre d'action ionic n'est pas terminée lorsqu'elle apparaît. C'est terminé lorsqu'elle se ferme.

Exemples d'implémentation pour Angular, React et Vue

La syntaxe change d'un framework à l'autre, mais le modèle mental ne change pas. Chaque version crée la même interaction : l'utilisateur clique sur l'icône de l'utilisateur, voit les options pour la photo de profil, choisit une action et l'application répond après que l'overlay est fermé.

Si vous gérez également les états hors ligne pour les téléchargements de médias, ce guide sur la création d'une écran hors ligne en Vue, Angular, React s'associe bien aux exemples ci-dessous car les actions photo mènent souvent directement à des flux dépendants du réseau. Exemple Angular

Dans Ionic Angular, l'approche la plus courante consiste à injecter

dans le composant ou la page. ActionSheetController Les équipes Angular se trompent généralement en l'un ou l'autre des deux endroits. Ils déplacent soit trop de logique dans les gestionnaires de boutons, soit ils oublient que la promesse de fermeture est le lieu plus sûr pour coordonner les transitions d'interface.

import { Component } from '@angular/core';
import { ActionSheetController } from '@ionic/angular';

@Component({
  selector: 'app-profile-photo',
  template: `
    <ion-button expand="block" (click)="openPhotoActions()">
      Profile Photo Options
    </ion-button>
  `
})
export class ProfilePhotoComponent {
  constructor(private actionSheetController: ActionSheetController) {}

  async openPhotoActions() {
    const actionSheet = await this.actionSheetController.create({
      header: 'Profile photo',
      subHeader: 'Choose what to do next',
      buttons: [
        {
          text: 'Take Photo',
          icon: 'camera',
          handler: () => {
            console.log('Open camera flow');
          }
        },
        {
          text: 'Choose from Library',
          icon: 'images',
          handler: () => {
            console.log('Open photo library flow');
          }
        },
        {
          text: 'Remove Current Photo',
          role: 'destructive',
          icon: 'trash',
          handler: () => {
            console.log('Remove current photo');
          }
        },
        {
          text: 'Cancel',
          role: 'cancel'
        }
      ]
    });

    await actionSheet.present();

    const { role } = await actionSheet.onDidDismiss();
    console.log('Action sheet dismissed with role:', role);
  }
}

Exemple React

Dans Ionic React,

vous donne un __CAPGO_KEEP_0__ fonctionnel compact qui s'intègre naturellement avec les gestionnaires d'événements. useIonActionSheet Le hook API de React est ergonomique, mais la même règle s'applique. Gardez le gestionnaire immédiat axé sur l'action choisie. Utilisez les appels de rappel de fermeture pour la nettoyage, les analyses ou l'état d'interface suivant.

import React from 'react';
import { IonButton, useIonActionSheet } from '@ionic/react';

const ProfilePhotoActions: React.FC = () => {
  const [presentActionSheet] = useIonActionSheet();

  const openPhotoActions = () => {
    presentActionSheet({
      header: 'Profile photo',
      subHeader: 'Choose what to do next',
      buttons: [
        {
          text: 'Take Photo',
          icon: 'camera',
          handler: () => {
            console.log('Open camera flow');
          }
        },
        {
          text: 'Choose from Library',
          icon: 'images',
          handler: () => {
            console.log('Open photo library flow');
          }
        },
        {
          text: 'Remove Current Photo',
          role: 'destructive',
          icon: 'trash',
          handler: () => {
            console.log('Remove current photo');
          }
        },
        {
          text: 'Cancel',
          role: 'cancel'
        }
      ],
      onDidDismiss: (event) => {
        console.log('Dismissed with role:', event.detail.role);
      }
    });
  };

  return (
    <IonButton expand="block" onClick={openPhotoActions}>
      Profile Photo Options
    </IonButton>
  );
};

export default ProfilePhotoActions;

React’s hook API is ergonomic, but the same rule applies. Keep the immediate handler focused on the chosen action. Use dismissal callbacks for cleanup, analytics, or follow-up UI state.

s'associe bien aux exemples ci-dessous car les actions photo mènent souvent directement à des flux dépendants du réseau.

In Ionic Vue, actionSheetController fonctionne proprement à l'intérieur de la Composition API.

<template>
  <ion-button expand="block" @click="openPhotoActions">
    Profile Photo Options
  </ion-button>
</template>

<script setup lang="ts">
import { IonButton, actionSheetController } from '@ionic/vue';

const openPhotoActions = async () => {
  const actionSheet = await actionSheetController.create({
    header: 'Profile photo',
    subHeader: 'Choose what to do next',
    buttons: [
      {
        text: 'Take Photo',
        icon: 'camera',
        handler: () => {
          console.log('Open camera flow');
        }
      },
      {
        text: 'Choose from Library',
        icon: 'images',
        handler: () => {
          console.log('Open photo library flow');
        }
      },
      {
        text: 'Remove Current Photo',
        role: 'destructive',
        icon: 'trash',
        handler: () => {
          console.log('Remove current photo');
        }
      },
      {
        text: 'Cancel',
        role: 'cancel'
      }
    ]
  });

  await actionSheet.present();

  const result = await actionSheet.onDidDismiss();
  console.log('Dismissed with role:', result.role);
};
</script>

Une différence pratique dans les projets Vue est où vous gardez les effets secondaires. Si votre application utilise des composables pour la logique de la caméra ou du sélectionneur de fichiers, appelez ceux à partir des gestionnaires et laissez le contrôleur code mince.

Conservez votre code spécifique au framework petit. La logique commerciale pour la caméra, l'importation, la suppression et les analyses doit vivre à l'extérieur de la configuration de la feuille d'actions.

Personnalisation et Styling avec CSS

La mise en forme par défaut de la feuille d'actions ionic est généralement suffisante pour un prototype. Ce n'est pas toujours suffisant pour une application personnalisée, et ce n'est certainement pas suffisant lorsque le design souhaite une mise en page plus serrée, une typographie différente ou une action destructive plus évidente.

Si votre équipe essaie de faire que l'application entière ait l'air moins comme un enveloppe web générique et plus comme un produit natif, cet article sur la configuration de base JS et CSS pour un look d'application native est un compagnon utile à la personnalisation de la mise en forme de la feuille d'actions.

Commencez par cssClass avant les surcharges globales

La première règle de mise en forme est simple. Ne ciblez pas tous les feuilles d'actions de l'application à moins que vous le vouliez vraiment. Utilisez cssClass pour définir une variante particulière.

const sheet = await actionSheetController.create({
  header: 'File actions',
  cssClass: 'file-actions-sheet',
  buttons: [
    { text: 'Rename' },
    { text: 'Delete', role: 'destructive' },
    { text: 'Cancel', role: 'cancel' }
  ]
});

Ensuite, stylez uniquement cette instance :

.file-actions-sheet {
  --background: #101418;
  --color: #f5f7fa;
  --backdrop-opacity: 0.4;
}

Cette approche est plus efficace que de poursuivre les sélecteurs plus tard.

Utilisez des propriétés personnalisées pour un thème large

Les propriétés CSS personnalisées sont la façon la plus rapide de changer l'ambiance générale sans se battre avec la structure du composant.

Les cas d'utilisation courants incluent :

• Couleur de fond et de texte lorsque votre application possède un palette personnalisée sombre.
• Opacité du fond d'écran lorsque la dimming par défaut semble trop faible ou trop lourde.
• Écartement et dimensionnement lorsque la densité visuelle doit correspondre au reste de votre interface.

.file-actions-sheet {
  --background: #1b1f24;
  --color: #ffffff;
  --backdrop-opacity: 0.32;
  --button-color: #dce3ea;
  --button-background-hover: #2a3138;
}

Utilisez les parties d'ombre lorsque vous avez besoin de précision

Lorsque le design demande des changements ciblés, les propriétés personnalisées peuvent ne pas suffire. C'est là que les parties d'ombre entrent en jeu. Elles vous permettent de styliser les zones internes du feuillet d'actions de manière plus directe.

.file-actions-sheet::part(container) {
  border-radius: 18px 18px 0 0;
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.24);
}

.file-actions-sheet::part(button) {
  font-weight: 600;
  letter-spacing: 0.01em;
}

.file-actions-sheet::part(backdrop) {
  backdrop-filter: blur(4px);
}

Ce qui ne fonctionne généralement pas bien, c'est l'over-styling du composant jusqu'à ce qu'il ne ressemble plus à un menu de choix système. Si vous avez besoin de cartes riches, de miniatures, de descriptions longues ou de dispositions de ligne complexes, vous avez dépassé le modèle du feuillet d'actions.

Une bonne passe de personnalisation devrait faire en sorte que le composant s'adapte à votre application, et non qu'il dissimule ce qu'il est.

Suivi avancé et considérations de plateforme

Les feuilles d'actions en production vivent dans un espace de décision plus vaste que la plupart des tutoriels ne le reconnaissent. Vous ne choisissez pas seulement les étiquettes des boutons. Vous décidez si l'overlay doit être rendu par la couche web d'Ionic ou délégué à l'interface native, combien de comportement spécifique à la plateforme vous souhaitez et comment vous vous assurez que le feuillet reste compréhensible pour tous les utilisateurs.

Composant web ou plugin natif

Si vous construisez une application Ionic standard, ion-action-sheet est généralement la valeur par défaut. C'est flexible, facile à styliser et fonctionne de manière cohérente avec le reste du système d'overlay de votre application.

Si votre application est basée sur Capacitor et que vous souhaitez que le système d'exploitation hôte rende le feuillet, la route native est @capacitor/action-sheet. Les documents d'Ionic décrivent un plugin autour de cela]} showActions(options) -> Promise<ShowActionsResult>installé avec npm install @capacitor/action-sheet et synchronisé avec npx cap sync, tout en notant que Les éléments PWA sont nécessaires dans les contextes web et PWA dans le Capacitor Documentation du plugin de feuille de dialogue d'action.

Cela vous donne une table de compromis pratique :

Utilisez le composant web lorsque la cohérence visuelle avec votre application compte plus. Utilisez le plugin natif lorsque la fidélité de la plateforme compte plus que le contrôle CSS profond.

Détails de la plateforme et de l'accessibilité

Ionic peut s'adapter aux modes iOS et Material Design, et cela affecte l'espace, la motion et le ton visuel global. N'assumez pas que votre mise en forme se comporte de la même manière dans les deux modes. Testez les deux intentionnellement, surtout si votre équipe impose un mode unique sur toutes les plateformes.

L'accessibilité est également négligée parce que les feuilles d'action ont l'air petites. Les bases sont toujours importantes :

• Utilisez du texte de bouton clair qui a du sens hors de contexte.
• Réservez destructive pour les actions risquées afin que l'interface communique l'intention.
• Conservation cancel explicite afin que l'utilisateur ait un chemin de sortie clair.
• Éviter l'ambiguïté décorative où plusieurs actions semblent similaires mais ont des résultats très différents.

Un utilisateur avec un lecteur d'écran ou des contraintes de charge cognitive n'expérimente pas les « overlays » simples comme simples si les étiquettes sont vagues.

Le point acéré ici est que les approches natives et web résolvent des problèmes différents. Le composant web vous donne plus de contrôle sur l'apparence et l'intégration. Le plugin natif vous donne une meilleure alignement sur la plateforme. Rien n'est automatiquement meilleur. La bonne réponse dépend de savoir si votre douleur actuelle d'application est la cohérence visuelle, la vitesse de mise en œuvre ou le comportement natif du système.

Les pièges de dépannage et la livraison de correctifs UI en direct

La plupart des bogues d'interface d'action d'Ionic ne se manifestent pas lorsque vous mettez en place trois boutons et que vous les cliquez dans un simulateur. Ils apparaissent plus tard, lorsque la feuille est stylisée, testée sur des appareils plus récents et combinée avec la navigation et les transitions d'état réelles.

Les bogues qui apparaissent après que le démo fonctionne

La première classe de bogue est le timing. La logique s'exécute trop tôt parce que le code n'attend pas la fermeture. Vous voyez les changements de route pendant que l'overlay est encore en train d'animer, ou les mises à jour d'état qui se disputent avec une autre composante de rendu.

La deuxième classe est la disposition. Un problème connu d'Ionic rapporte que la feuille d'action peut chevaucher la zone de sécurité inférieure sur certains appareils iOS, surtout lorsque --ion-safe-area-bottom est non nul, et le rapport de problème note qu'il peut même être reproduit dans la démo des docs d'Ionic le problème GitHub concernant l'overlap de la zone de sécurité inférieure. C'est exactement le type de problème que les équipes manquent jusqu'à la fin de la phase de test QA car cela dépend de la forme du appareil, du mode et du CSS personnalisé.

Une solution pratique pour la zone de sécurité

Si votre application affiche la feuille trop proche de l'aire de l'indicateur d'accueil, commencez par un override scoping plutôt qu'un patch global large.

.safe-area-sheet::part(container) {
  padding-bottom: calc(env(safe-area-inset-bottom) + 8px);
}

Appliquez ensuite la classe lors de la création de la feuille d'action :

const sheet = await actionSheetController.create({
  header: 'More actions',
  cssClass: 'safe-area-sheet',
  buttons: [
    { text: 'Archive' },
    { text: 'Delete', role: 'destructive' },
    { text: 'Cancel', role: 'cancel' }
  ]
});

Cela ne remplacera pas les tests de dispositif appropriés, mais cela vous donne un endroit concret pour commencer sans modifier chaque surcouche de l'application.

Pourquoi les mises à jour en temps réel sont importantes pour les défauts d'interface utilisateur

Les réalités pratiques des opérations de mise en production deviennent évidentes. Une régression de la zone de sécurité, une règle de marge brisée ou une couleur de bouton destructive mauvaise se trouvent souvent dans JavaScript ou CSS. Si ce bug est expédié en production, attendre une mise en production complète de l'application peut transformer un petit défaut visuel en jours de frustration pour les utilisateurs.

Une option pratique est un service de mise à jour en temps réel pour les applications Capacitor . Par exemple, Capgo fournit des ensembles de fichiers web mis à jour afin que les équipes puissent envoyer les correctifs de JavaScript, CSS, copie, configuration et ressources sans attendre la revue de l'application sur l'app store, ce qui est directement pertinent lorsque un bug de style de feuille d'action ou d'overlay glisse entre les doigts de la phase de test QA.

Les surcouche d'interface utilisateur sont exactement le type de fonctionnalité où ce filet de sécurité paye de ses effets. Ils sont très visibles, faciles à briser avec de petites modifications de style et généralement réparable sans reconstruire le code natif.

If votre équipe livre régulièrement des applications Ionic ou Capacitor Capgo vaut la peine d'être évalué comme partie de votre flux de mise à jour. Il vous donne un moyen de pousser des correctifs pour la couche web pour des problèmes comme les bugs de mise en page des feuilles d'actions, les régressions de style et les erreurs de copie après la mise en production, tout en gardant le contrôle sur les canaux de déploiement et le comportement de mise à jour.

Continuez avec Ionic Action Sheet : Guide complet pour 2026

Si vous utilisez Ionic Action Sheet : Guide complet pour 2026 pour planifier la migration et les opérations d'entreprise, connectez-le avec Capgo Enterprise pour le flux de workflow dans Capgo Enterprise Ionic Enterprise Plugin Alternatives pour le flux de workflow dans Ionic Enterprise Plugin Alternatives Capgo Alternatives pour le flux de travail du produit dans Capgo Alternatives, Capgo Consulting pour le flux de travail du produit dans Capgo Consulting, et Capgo Support Premium pour le flux de travail du produit dans Capgo Support Premium.