Ionic Action Sheet : le guide complet pour 2026

Vous êtes probablement dans l’une de ces deux situations. Soit vous avez besoin d’une façon propre d’afficher quelques actions contextuelles sans encombrer votre écran de boutons supplémentaires, soit vous avez déjà déployé une Ionic Action Sheet et vous avez découvert que la version de démo facile n’est pas la même chose qu’une implémentation prête pour la production.

Cette différence compte. Une action sheet semble simple, mais elle se situe à l’intersection du design d’interaction, des API du framework, du comportement des plateformes, de l’accessibilité et de la maintenance post-release. Si vous ne la considérez que comme une popup avec des boutons, vous passerez à côté des éléments qui cassent généralement en fin de QA.

Table des matières

• Introduction à l’Action Sheet d’Ionic
  • Pourquoi les équipes continuent de l’utiliser
• Comprendre l'Action Sheet Controller et API
  • Pourquoi l’API est piloté par le 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 du dépannage et déploiement de correctifs UI en live
  • Les bugs qui apparaissent après la démo
  • Un correctif pratique pour la safe area
  • Pourquoi les live updates comptent pour les défauts UI

Introduction à l’Action Sheet d’Ionic

L’action sheet Ionic est l’outil idéal lorsque l’utilisateur doit effectuer 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 de place permanente dans la mise en page principale.

Dans Ionic, ce modèl’est resté cohérent depuis longtemps. Les applications Ionic antérieures utilisaient le $ionicActionSheet service, que TutorialsPoint décrit comme un panneau qui glisse depuis le bas de l’écran et 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 visiblement le même, ce qui fait de ce composant l’un des exemples les plus clairs de la manière dont Ionic préserve les modèles d’interface mobile d’une génération de framework à l’autre dans le résumé de la documentation de l’action sheet Ionic 1 par TutorialsPoint.

Cette continuité est utile dans les projets réels. Cela signifie que le composant n’est pas une abstraction à la mode qui changeait à chaque release. C’est un modèle mobile-first stable qui correspond bien aux menus d’options iOS et Android, et qui reste naturel dans les projets Angular, React et Vue.

Pourquoi les équipes continuent de l’utiliser

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 fonctionne mal lorsque l’utilisateur a besoin d’explications, de validation ou de plusieurs champs de formulaire.

Une règle simple :

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

Règle pratique : Si les libellés des boutons ne sont pas explicites sans un 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 relie le web au natif code mérite d'être gardée en tête quand vous décidez où l'action sheet doit être implémentée.

Comprendre l'Action Sheet Controller et API

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

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

Au quotidien avec Ionic, l’approche basée sur un contrôleur est généralement la plus propre, car l’action sheet est éphémère. On ne veut pas d’un gros bloc de balisage template dans la page pour un menu qui n’apparaît qu’après un tap sur une icône de débordement.

La documentation officielle d’Ionic définit l’Action Sheet comme un dialogue modal qui nécessite une fermeture par l’utilisateur, et elle accorde beaucoup d’importance aux méthodes du cycle de vie de fermeture, comme onDidDismiss pour la logique post-sélection dans la documentation Ionic Action Sheet API. Cette conception vous indique comment structurer votre code. Présentez d’abord. Réagissez après la fermeture. Ne liez pas la logique critique à des hypothèses sur le timing.

Les options qui comptent vraiment

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

C'est souvent dans la configuration des boutons que les erreurs arrivent. Un bouton typique peut inclure :

• text pour l'étiquette visible.
• icon si vous souhaitez un indice 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 for dangerous actions like delete. Use cancel pour la voie de sortie. Ces rôles influencent la manière dont l’action sheet présente les options et dont les utilisateurs lisent la liste sous pression.

Les actions dangereuses doivent se situer à la périphérie de l'ensemble des choix, et non mélangées aux actions neutres avec le même poids visuel.

La fermeture fait partie du contrat

Un bug classique se présente ainsi : un développeur ouvre une action sheet, suppose que le résultat du handler suffit, puis déclenche une navigation ou une mise à jour d'état avant que l'overlay ne se soit entièrement refermée. Cela peut provoquer des transitions saccadées, un état obsolète ou des conditions de course dans les tests.

Utilisez le cycle de vie de manière intentionnelle :

1. Créez la 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 schéma est ennuyeux, et c'est précisément pour ça qu'il fonctionne.

Voici un exemple simple au style Angular de la structure :

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

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

La syntaxe change d'un framework à l'autre, 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 de 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éation d'un écran hors ligne en Vue, Angular ou React s'associe parfaitement aux exemples ci-dessous, car les actions sur les photos mènent souvent directement à des flux dépendants 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 se trompent généralement à l'un de ces deux endroits. Soit elles mettent 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;

Le hook API de 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 d'UI de suivi.

Exemple Vue

Avec Ionic Vue, actionSheetController fonctionne proprement dans 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, c'est l'endroit où vous placez les effets de bord. Si votre application 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 application de marque, et il est clairement insuffisant quand le design demande un espacement plus serré, une typographie différente ou une action destructive plus évidente.

Si votre équipe veut que l'ensemble de l'app ressemble moins à un wrapper web générique et davantage à un produit natif, cet article sur Config JS et CSS de base pour un rendu natif d'app est un complément utile pour le style des action sheets.

Commencez par cssClass avant les overrides globaux

La première règle de style est simple. Ne ciblez pas tous les action sheets de l'app, sauf si c'est voulu. Utilisez cssClass pour limiter la portée à une variante spécifique.

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 du texte lorsque votre app possède une palette sombre personnalisée.
• Opacité de l’arrière-plan lorsque l’assombrissement par défaut semble trop faible ou trop intense.
• Espacement et dimensions 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 shadow parts pour plus de précision

Quand le design réclame des modifications ciblées, les propriétés personnalisées ne suffisent parfois pas. C’est là que les Shadow Parts prennent tout leur sens : ils vous permettent de styliser plus directement les zones internes de la feuille d’actions.

.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 marche généralement pas bien, c’est de trop styliser le composant jusqu’à ce qu’il ne ressemble plus à un menu de choix au niveau système. Si vous avez besoin de cartes riches, de vignettes, de descriptions longues ou de dispositions de lignes complexes, la feuille d’actions n’est plus le bon pattern.

Une bonne personnalisation doit adapter le composant à votre application, sans masquer sa nature.

Sujets avancés et considérations par plateforme

Les action sheets en production s’inscrivent dans un espace de décision plus large que ne le laissent supposer la plupart des tutoriels. Il ne s’agit pas seulement de choisir les libellés des boutons. Vous devez décider si l’overlay doit être rendu par la couche web d’Ionic ou délégué à l’UI native, à quel point vous souhaitez un comportement spécifique à la plateforme, et comment vous assurer que la feuille reste compréhensible pour tous les utilisateurs.

Composant web 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 l'action sheet, la voie native est @capacitor/action-sheet. Ionic documente ce plugin autour showActions(options) -> Promise<ShowActionsResult>, installé avec npm install @capacitor/action-sheet et synchronisé avec npx cap sync, tout en précisant que les PWA Elements sont requis dans les contextes web et PWA dans l' Documentation du plugin Capacitor Action Sheet.

Cela donne un tableau comparatif concret :

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

Mode plateforme et détails d’accessibilité

Ionic peut s’adapter aux modes iOS et Material Design, ce qui joue sur l’espacement, les animations et le rendu visuel global. Ne partez pas du principe que votre style se comporte de la même façon dans les deux modes. Testez-les tous les deux volontairement, surtout si votre équipe impose un seul mode sur toutes les plateformes.

L’accessibilité est aussi souvent oubliée, car les action sheets paraissent anodines. Les bases restent importantes :

• Utilisez un libellé de bouton clair qui reste compréhensible hors contexte.
• À réserver destructive pour les actions à risque afin que l’interface exprime l’intention.
• Conservez cancel explicite pour offrir à l’utilisateur une issue claire.
• Évitez l’ambiguïté décorative où plusieurs actions se ressemblent mais ont des conséquences très différentes.

Un utilisateur avec un lecteur d’écran ou des contraintes cognitives ne perçoit pas les overlays « simples » comme tels si les libellés sont vagues.

Le point délicat ici est que les approches native 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 offre un meilleur alignement sur la plateforme. Aucun des deux n'est meilleur par défaut. Le bon choix dépend de votre problème actuel : cohérence visuelle, rapidité d'implémentation ou comportement natif du système.

Pièges du dépannage et déploiement de correctifs UI en live

La plupart des bugs des action sheets Ionic n'apparaissent pas quand vous branchez trois boutons pour la première fois et les testez dans un simulateur. Ils apparaissent plus tard, quand l'action sheet est stylisée, testée sur des appareils plus récents et combinée à de la 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 le timing. La logique s'exécute trop tôt parce que le code n'attend pas la fermeture. Vous voyez des changements de route alors que l'overlay est encore en cours d'animation, ou des mises à jour d'état qui entrent en concurrence avec le rendu d'un autre composant.

La deuxième catégorie concerne la mise en page. Un problème Ionic connu rapporte que l'action sheet peut chevaucher la zone de sécurité inférieure dans certaines conditions sur appareils iOS, en particulier lorsque --ion-safe-area-bottom est non nul, et le rapport indique qu'il peut même être reproduit dans la démo de la doc Ionic dans le problème GitHub de chevauchement de la zone de sécurité inférieure. C’est précisément le genre de problème que les équipes manquent 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 la feuille trop près de la zone de l’indicateur d’accueil, commencez par une surcharge ciblée plutôt que par un correctif 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 la feuille d’actions :

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 sur appareil, mais cela vous donne un point de départ concret sans modifier tous les overlays de l’application.

Pourquoi les live updates comptent pour les défauts UI

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

Une option concrète est un service live update pour les applications Capacitor. Par exemple, Capgo il permet de livrer des bundles web mis à jour afin que les équipes puissent déployer des correctifs JS, CSS, de contenu, de config et d'assets sans attendre la validation des stores, ce qui est directement utile lorsqu'un bug de style ou d'overlay d'action sheet échappe à la QA.

Les overlays d'UI sont exactement le genre de fonctionnalité où ce filet de sécurité fait la différence. Ils sont très visibles, faciles à casser par 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 mérite d'être évalué dans votre workflow de release. Cela vous permet de pousser des correctifs côté web pour des problèmes comme des bugs de layout d'action sheet, des régressions de style ou des erreurs de contenu 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 Entreprise 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, Conseil Capgo pour le workflow produit dans Capgo Consulting, et Support Premium Capgo pour le workflow produit dans Capgo Premium Support.