Ionic Action Sheet : le guide complet pour 2026

Vous êtes probablement dans l'une de ces deux situations. Soit vous avez besoin d'un moyen propre d'afficher quelques actions contextuelles sans encombrer votre écran de boutons supplémentaires, soit vous avez déjà livré un action sheet Ionic et découvert que la version de démo simple n'est pas la même chose qu'une implémentation prête pour la production.

Cet écart compte. Un action sheet semble simple, mais il se situe à l'intersection du design d'interaction, des API du framework, du comportement de la plateforme, de l'accessibilité et de la maintenance après release. Si vous le traitez uniquement comme une popup avec des boutons, vous passerez à côté des points qui cassent généralement en fin de QA.

Table of Contents

• Introduction à l'action sheet Ionic
  • Pourquoi les équipes l'utilisent toujours
• Comprendre l'Action Sheet Controller et API
  • Pourquoi l’API est piloté 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 overrides globaux
  • Use custom properties for broad theming
  • Utilisez les shadow parts pour plus de précision
• Sujets avancés et considérations par plateforme
  • Composant web ou plugin natif
  • Mode plateforme et détails d'accessibilité
• Pièges de dépannage et déploiement de correctifs UI via Live Update
  • Les bugs qui apparaissent quand la démo fonctionne
  • Un correctif pratique pour la safe area
  • Why live updates matter for UI defects

Introduction à l'action sheet Ionic

L'action sheet d'Ionic est l'outil idéal quand l'utilisateur doit faire un choix rapide et ciblé 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 mise en page principale.

Dans Ionic, ce pattern est resté cohérent pendant longtemps. Les anciennes applications Ionic utilisaient le $ionicActionSheet service, que TutorialsPoint décrit comme un volet qui glisse depuis le bas de l'écran et qui s'affiche en injectant le service et en appelant show() in the controller. Modern apps use ion-action-sheet, mais le modèle d'interaction reste reconnaissable, ce qui fait de ce composant l'un des meilleurs exemples de la manière dont Ionic préserve les patterns d'UI mobile à travers les générations de frameworks dans le résumé de la documentation de l'action sheet Ionic 1 de TutorialsPoint.

Cette continuité est précieuse dans les projets réels. Cela signifie que le composant n'est pas une abstraction éphémère qui change à chaque release. C'est un pattern stable, conçu pour le mobile, qui s'adapte parfaitement aux menus d'options iOS et Android, et qui reste naturel dans les projets Angular, React et Vue.

Pourquoi les équipes l'utilisent toujours

Une action sheet fonctionne bien lorsque l'utilisateur comprend déjà le contexte et n'a besoin que d'une liste compacte d'étapes suivantes. Elle est moins adaptée lorsque l'utilisateur nécessite des explications, une validation ou plusieurs champs de formulaire.

Une règle simple peut vous aider :

• Utilisez une action sheet pour des menus de décision courts liés à un élément spécifique.
• Utilisez une alerte lorsque vous avez besoin d'une confirmation avec un minimum d'options.
• Utilisez une modale when the user needs more content, inputs, or scrolling.

Règle pratique : Si les labels des boutons ne sont pas explicites sans texte de paragraphe supplémentaire, ne forcez pas l'interaction dans un action sheet.

Dans les apps hybrides, ce pattern s'intègre parfaitement au modèle web-to-native. L'UI est assez simple pour être rendue dans la couche web, tout en conservant un ressenti natif sur les appareils tactiles. Si votre équipe développe avec Capacitor et souhaite mieux comprendre cette frontière, cette analyse de comment Capacitor fait le pont entre le web et le code natif mérite votre attention lors de la décision de l'emplacement de l'action sheet.

Comprendre l'Action Sheet Controller et API

L'action sheet devient facile à appréhender dès que vous cessez de la considérer comme un simple composant inline. Elle se comporte plutôt comme un overlay temporaire avec un cycle de vie. Vous la créez, vous la présentez, vous attendez l'utilisateur, puis vous gérez le résultat après la fermeture.

Pourquoi l’API est piloté par un contrôleur

Dans le travail quotidien sur Ionic, l'approche par contrôleur est généralement l'option la plus propre car l'action sheet est éphémère. Vous ne voulez pas qu'un gros bloc de markup de template encombre votre page pour un menu qui n'apparaît qu'après un clic sur une icône d'overflow.

La doc officielle d'Ionic définit l'Action Sheet comme une boîte de dialogue modale qui nécessite une fermeture par l'utilisateur, et ils accordent une grande importance aux méthodes de cycle de vie de fermeture telles que onDidDismiss pour la logique de post-sélection dans l' documentation Ionic Action Sheet API. Ce design vous indique comment structurer votre code. Présentez d'abord. Réagissez après la fermeture. Ne liez pas la logique critique à des suppositions de timing.

Les options qui comptent vraiment

La plupart des équipes n'ont besoin que d'un petit sous-ensemble de API, mais elles doivent utiliser ce sous-ensemble correctement.

La configuration des boutons est la source d'erreurs habituelle. Un bouton classique peut inclure :

• text pour le label visible.
• icon si vous voulez un indicateur visuel.
• handler pour la logique de callback immédiate.
• role pour le comportement sémantique et le style de la plateforme.

role n'est pas décoratif. Utilisez destructive pour les actions critiques comme la suppression. Utilisez cancel pour l'option d'annulation. Ces rôles influencent la manière dont l'action sheet présente les choix et la façon dont les utilisateurs lisent la liste sous pression.

Les actions critiques doivent se situer à la limite de l'ensemble des choix, et non être mélangées à des actions neutres ayant le même poids visuel.

L'annulation fait partie du contrat

Un bug courant est le suivant : un développeur ouvre un action sheet, suppose que le résultat du handler est suffisant, puis déclenche une navigation ou une mise à jour d'état avant que l'overlay ne soit totalement fermé. Cela peut provoquer des transitions saccadées, un état obsolète ou des race conditions lors des tests.

Utilisez le cycle de vie de manière intentionnelle :

1. Créez le sheet.
2. await present().
3. await onDidDismiss().
4. Lisez le rôl’ou les données retournés.
5. Déclenchez l'action suivante.

Ce pattern est simple, et c'est précisément pour cela qu'il fonctionne.

Voici un exemple concret de la structure en style Angular :

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 ne devez retenir qu'une seule chose de API, retenez ceci : un action sheet Ionic n'est pas terminé lorsqu'il apparaît. Il est terminé lorsqu'il se ferme.

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

La syntaxe change selon le framework, mais le modèle mental reste le même. Chaque version crée la même interaction : l'utilisateur appuie sur l'avatar, voit les options pour la photo de profil, choisit une action, et l'application répond une fois l'overlay fermé.

Si vous gérez également les états hors ligne pour l'upload de médias, ce guide sur créer un écran hors ligne en Vue, Angular ou React s'accorde parfaitement avec les exemples ci-dessous, car les actions liées aux photos mènent souvent directement à des flux dépendant du réseau.

Exemple Angular

Dans Ionic Angular, l'approche la plus courante consiste à injecter ActionSheetController dans le composant ou la page.

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);
  }
}

Les équipes Angular font généralement l'erreur à deux endroits. Soit elles déplacent trop de logique dans les gestionnaires de boutons, soit elles oublient que la promesse de fermeture est l'endroit le plus sûr pour coordonner les transitions d'interface.

Exemple React

Avec Ionic React, useIonActionSheet vous offre un API fonctionnel et compact qui s'intègre naturellement aux gestionnaires d'événements.

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;

L’API de hook React est ergonomique, mais la même règle s'applique. Gardez le gestionnaire immédiat concentré sur l'action choisie. Utilisez les callbacks de fermeture pour le nettoyage, l'analytics ou l'état de l'UI suivant.

Exemple Vue

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

<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 réside dans l'endroit où vous gérez les effets de bord. Si votre app utilise des composables pour la logique de caméra ou de sélecteur de fichiers, appelez-les depuis les gestionnaires et gardez le code du contrôleur léger.

Gardez votre code spécifique au framework léger. La logique métier pour la caméra, l'upload, la suppression et l'analytics doit rester en dehors de la configuration de l'action sheet.

Personnalisation et style avec CSS

Le style par défaut de l'action sheet Ionic est généralement suffisant pour un prototype. Il ne l'est pas toujours pour une app à l'image de marque, et il est clairement insuffisant quand le design exige un espacement plus serré, une typographie différente ou une action destructive plus explicite.

Si votre équipe cherche à ce que l'app ressemble moins à un simple wrapper web et davantage à un produit natif, cet article sur config JS et CSS de base pour un rendu d'app native est un complément utile pour le style de l'action sheet.

Commencez par cssClass avant les overrides globaux

La première règle de style est simple. Ne ciblez pas chaque action sheet de l'app, sauf si c'est voulu. Utilisez cssClass pour limiter la portée à 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, stylisez uniquement cette instance :

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

Cette approche passe mieux à l'échelle que de traquer les sélecteurs plus tard.

Use custom properties for broad theming

Les propriétés CSS personnalisées sont le moyen le plus rapide de changer l'aspect général sans lutter contre la structure du composant.

Les cas d'usage courants incluent :

• Couleur de fond et de texte lorsque votre app possède une palette sombre personnalisée.
• Opacité de l'overlay quand l'assombrissement par défaut semble trop faible ou trop prononcé.
• Espacement et dimensionnement quand 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 shadow parts pour plus de précision

Dès que le design exige des modifications ciblées, les propriétés personnalisées peuvent ne pas suffire. C'est là que les Shadow Parts interviennent. Elles vous permettent de styliser plus directement les zones internes de l'action sheet.

.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 fonctionne rarement, c'est de trop styliser le composant au point qu'il ne ressemble plus à un menu système. Si vous avez besoin de cartes riches, de miniatures, de descriptions longues ou de mises en page de lignes complexes, le pattern de l'action sheet n'est plus adapté.

Une bonne personnalisation doit permettre au composant de s'intégrer à votre app, sans masquer sa nature.

Sujets avancés et considérations de plateforme

Les action sheets en production impliquent des décisions plus larges que ce que la plupart des tutoriels admettent. Vous ne choisissez pas seulement les labels des boutons. Vous décidez si l'overlay doit être rendu par la couche web d'Ionic ou délégué à l'UI native, quel degré de comportement spécifique à la plateforme vous souhaitez, et comment garantir que le menu reste compréhensible pour tous les utilisateurs.

Web component ou plugin natif

Si vous développez une application Ionic standard, ion-action-sheet est généralement l'option par défaut. Elle 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 repose sur Capacitor et que vous souhaitez que le système d'exploitation hôte affiche la feuille, la voie native est @capacitor/action-sheetLa documentation Ionic pour ce plugin tourne autour de showActions(options) -> Promise<ShowActionsResult>, installé avec npm install @capacitor/action-sheet et synchronisé avec npx cap sync, tout en notant que les PWA Elements sont requis dans les contextes web et PWA dans le plugin Capacitor Action Sheet.

Voici un tableau comparatif pour vous aider à choisir :

Utilisez le composant web quand la cohérence visuelle avec votre app est prioritaire. Utilisez le plugin natif quand la fidélité à la plateforme prime sur un contrôle CSS poussé.

Mode plateforme et détails d'accessibilité

Ionic peut s'adapter aux modes iOS et Material Design, ce qui impacte l'espacement, les animations et le ton visuel global. Ne partez pas du principe que votre style se comporte de la même manière dans les deux modes. Testez les deux cas volontairement, surtout si votre équipe impose un mode unique sur toutes les plateformes.

L'accessibilité est aussi souvent négligée car les action sheets paraissent anodines. Les bases restent essentielles :

• Utilisez un texte de bouton clair qui reste compréhensible hors contexte.
• Réservez destructive les actions risquées pour que l'interface communique l'intention.
• Restez cancel explicite pour que l'utilisateur ait une issue claire.
• Évitez l'ambiguïté décorative où plusieurs actions se ressemblent mais ont des résultats très différents.

Un utilisateur avec un lecteur d'écran ou des contraintes cognitives ne trouvera pas les overlays « simples » si les labels sont vagues.

La nuance ici est que les approches native et web résolvent des problèmes différents. Le composant web offre plus de contrôle sur l'apparence et l'intégration. Le plugin natif offre un meilleur alignement avec la plateforme. L'un n'est pas automatiquement meilleur que l'autre. La bonne réponse dépend de votre besoin actuel : cohérence visuelle, vitesse d'implémentation ou comportement natif du système.

Pièges de débogage et déploiement de correctifs UI via Live Update

La plupart des bugs d'action sheet Ionic n'apparaissent pas quand vous connectez trois boutons pour les tester dans un simulateur. Ils surgissent plus tard, quand le composant est stylisé, testé sur des appareils récents et combiné à une navigation et des transitions d'état réelles.

Les bugs qui apparaissent après la démo

La première catégorie de bugs est liée au timing. La logique s'exécute trop tôt car le code n'attend pas la fermeture. Vous observez des changements de route alors que l'overlay est encore en animation, ou des mises à jour d'état qui entrent en conflit avec le rendu d'un autre composant.

La deuxième catégorie concerne le layout. Un problème connu sur Ionic indique que l'action sheet peut chevaucher la zone de sécurité inférieure (safe area) sur certains appareils iOS, surtout quand --ion-safe-area-bottom est non nul, et le rapport d'incident précise qu'il peut même être reproduit dans la démo de la documentation d'Ionic dans the GitHub issue about bottom safe area overlap. C'est exactement le genre de problème que les équipes ne détectent qu'en fin de QA, car il dépend de la forme de l'appareil, du mode et du CSS personnalisé.

Un correctif pratique pour la safe area

Si votre application affiche l'action sheet trop près de la zone de l'indicateur d'accueil, commencez par un override ciblé plutôt que par un patch global.

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

Appliquez ensuite la classe lors de la création de l'action sheet :

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 remplace pas des tests réels sur appareil, mais cela vous donne un point de départ concret sans modifier tous les overlays de l'app.

Why live updates matter for UI defects

Les réalités concrètes des opérations de release deviennent évidentes. Une régression de la safe area, une règle de padding cassée ou une mauvaise couleur sur un bouton destructif résident souvent dans le JavaScript ou le CSS. Si ce bug est déployé en production, attendre une release complète sur les stores peut transformer un petit défaut visuel en plusieurs jours de frustration pour les utilisateurs.

Une option pratique est un service live update pour les applications Capacitor. Par exemple, Capgo il livre des bundles web mis à jour pour que les équipes puissent déployer des correctifs JS, CSS, de texte, de config ou d'assets sans attendre la validation des stores, ce qui est crucial quand un bug de style d'action sheet ou d'overlay échappe à la QA.

Les overlays d'interface sont précisément le type de fonctionnalité où ce filet de sécurité est rentable. Ils sont très visibles, faciles à casser avec de petits changements de style, et généralement réparables sans reconstruire le code natif.

Si votre équipe déploie régulièrement des applications Ionic ou Capacitor, Capgo vaut la peine d'être évalué dans votre workflow de release. Cela vous permet de pousser des correctifs sur la couche web pour des problèmes comme des bugs de layout d'action sheet, des régressions de style ou des erreurs de texte après la release, tout en gardant le contrôle sur vos canaux de déploiement et le comportement des mises à jour.

Continuer : Ionic Action Sheet : Le guide complet pour 2026

Si vous utilisez Ionic Action Sheet : le guide complet pour 2026 pour planifier la migration et les opérations d'entreprise, connectez-l’à Capgo Enterprise pour le workflow produit dans Capgo Enterprise, Alternatives aux plugins Ionic Enterprise pour le workflow produit dans les alternatives aux plugins Ionic Enterprise, Alternatives à Capgo pour le workflow produit dans les alternatives à Capgo Consulting Capgo pour le workflow produit dans le Consulting Capgo, et Capgo Support Premium pour le workflow produit dans Capgo Premium Support.