@1024pix/pix-ui 24.1.0 → 24.2.1

package/docs/good-practices-design.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Développement/Bonnes pratiques/Design' />
+<Meta title="Développement/Bonnes pratiques/Design" />
 
 # Bonnes pratiques design
 
@@ -8,23 +8,16 @@ import { Meta } from '@storybook/addon-docs/blocks';
 
 - les **noms de branches** commencent par `pix-ui`.
 
-
 - Les **noms des fichiers** suivent l'exemple de la pix-tooltip.
-*Par exemple, pour les styles, on recomandera de rajouter `_` devant le nom du fichier pour indiquer que c'est un ["fichier partiel Sass"](https://sass-lang.com/guide#topic-4).*
-
-
-- Les **noms des composants** commencent par `Pix` et sont écrit en *PascalCase*.
-*Par exemple, un composant bouton devient : `PixButton`.*
+  _Par exemple, pour les styles, on recomandera de rajouter `_` devant le nom du fichier pour indiquer que c'est un ["fichier partiel Sass"](https://sass-lang.com/guide#topic-4)._
 
+- Les **noms des composants** commencent par `Pix` et sont écrit en _PascalCase_.
+  _Par exemple, un composant bouton devient : `PixButton`._
 
-- Les **noms des propriétés des composants** sont écrit en *camelCase*.
+- Les **noms des propriétés des composants** sont écrit en _camelCase_.
 
 ```hbs
-<PixSelect
-  @options={{options}}
-  @onChange={{onChange}}
-  @selectedOption="1"
-/>
+<PixSelect @options={{options}} @onChange={{onChange}} @selectedOption='1' />
 ```
 
 - Les **noms des classes CSS** suivent la convention [BEM](https://github.com/1024pix/pix/blob/dev/docs/CSS.md).
@@ -40,7 +33,7 @@ Il faut garder une **responsabilité unique** par composant.
 - Un composant doit interagir uniquement dans son scope afin de ne pas devenir trop complexe et provoquer des effets de bord.
 - Un composant trop complexe induit plusieurs paramètres ce qui rend donc son utilisation délicate.
 
-Par exemple, si l'intention d'un composant est d'être un bouton (dans notre existant, *`PixButton`*) et qu'on le fait évoluer pour qu'il puisse devenir aussi un lien, il perd alors son intention d'origine (le nommage du composant *`PixButton`* ne fait alors plus sens) et prend trop de responsabilités.
+Par exemple, si l'intention d'un composant est d'être un bouton (dans notre existant, _`PixButton`_) et qu'on le fait évoluer pour qu'il puisse devenir aussi un lien, il perd alors son intention d'origine (le nommage du composant _`PixButton`_ ne fait alors plus sens) et prend trop de responsabilités.
 
 Il conviendra alors d'avoir un composant pour un bouton et un autre pour un lien.
 
@@ -55,16 +48,14 @@ Lorsqu'une autre personne va mettre à jour Pix UI dans une application, il est
 ## Rétrocompatibilité / Deprecated
 
 Il est aussi possible de signaler ces changements comme dépréciés :
+
 - Ne pas supprimer le composant actuel mais l'indiquer comme déprécié afin qu'il soit toujours utilisable le temps de faire les modifications. À terme, l'élément déprécié sera supprimé dans une nouvelle version majeure de Pix UI.
 
 Exemple d'un composant déprécié :
+
 ```hbs
 <PixSelect>
-  <NewPixSelect
-    @options={{options}}
-    @onChange={{onChange}}
-    @selectedOption="1"
-  />
+  <NewPixSelect @options={{options}} @onChange={{onChange}} @selectedOption='1' />
 </PixSelect>
 ```
 

package/docs/good-practices-responsive.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Développement/Bonnes pratiques/Responsive' />
+<Meta title="Développement/Bonnes pratiques/Responsive" />
 
 # Bonnes pratiques responsive
 
@@ -14,7 +14,6 @@ Ils sont décris dans le fichier `addon/styles/_breakpoints.scss` et utilisables
 
 Par exemple, ici le style s'applique si on a moins la largeure d'une tablette.
 
-
 ```scss
 @include device-is('tablet') {
   padding: 32px 58px;
@@ -23,6 +22,7 @@ Par exemple, ici le style s'applique si on a moins la largeure d'une tablette.
 ```
 
 Le différents devices disponibles sont :
+
 - `mobile`
 - `tablet`
 - `desktop`

package/docs/good-practices-style-css.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Développement/Bonnes pratiques/Style CSS' />
+<Meta title="Développement/Bonnes pratiques/Style CSS" />
 
 # Style CSS / SCSS
 
@@ -9,25 +9,25 @@ import { Meta } from '@storybook/addon-docs/blocks';
 - Les variables se trouvent dans leur fichier scss respectif: `_breakpoints.scss`, `_colors.scss`, `_fonts.scss`.
 - Chaque composant a son fichier scss qui sont importés dans `addon/styles/addon.scss`.
 
-~~~javascript
+```javascript
 @import 'pix-tooltip';
-~~~
+```
 
 ## Rendre surchargeable le SCSS
 
 Passer `...attributes` au composant.
 
-~~~html
-<div class="pix-background-header" ...attributes>
-~~~
+```html
+<div class="pix-background-header" ...attributes></div>
+```
 
 ## Convention BEM
 
 Nos classes suivent la convention [BEM](https://github.com/1024pix/pix/blob/dev/docs/CSS.md).
 
-~~~javascript
+```javascript
 class='pix-tooltip__content'
-~~~
+```
 
 ## rem, spacing...
 
@@ -37,4 +37,4 @@ Il est recommandé d'utiliser le `rem` plutot que `px`.
 Concernant les niveaux de textes, se référer a ZeroHeight [ici](https://zeroheight.com/8dd127da7/p/20e4df-typographie/b/974231).
 
 Utiliser les **variables Sass** déjà existantes.
-*Par exemple, vérifier dans les fichiers `_fonts.scss` et `_colors.scss`. Si elles n'existent pas, les rajouter au bon endroit.*
+_Par exemple, vérifier dans les fichiers `_fonts.scss` et `_colors.scss`. Si elles n'existent pas, les rajouter au bon endroit._

package/docs/good-practices-tests.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Développement/Bonnes pratiques/Tests' />
+<Meta title="Développement/Bonnes pratiques/Tests" />
 
 # Bonnes pratiques de test
 

package/docs/make-a-release.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Développement/Faire une release' />
+<Meta title="Développement/Faire une release" />
 
 # Faire une release
 
@@ -19,11 +19,12 @@ Par ailleurs, sur Pix UI une release signifie aussi la mise à jour automatique
 ## Effectuer la release, méthode via slack (conseillée)
 
 Aller dans le canal slack dédié aux releases : [#tech-releases](https://1024pix.slack.com/archives/CVAMDQYHY), puis taper la commande suivante :
+
 - `/publish-pix-ui <version_souhaitée>`
-    `<version_souhaitée>` peut prendre 3 valeurs :
-    - `patch` : correctif de bug
-    - `minor` : modifications n'apportant pas de changement dans l'utilisation de Pix UI
-    - `major` : modifications apportant des breaking changes
+  `<version_souhaitée>` peut prendre 3 valeurs :
+  - `patch` : correctif de bug
+  - `minor` : modifications n'apportant pas de changement dans l'utilisation de Pix UI
+  - `major` : modifications apportant des breaking changes
 
 Vous devriez voir apparaître dans le canal un premier message (visible uniquement par vous) de Pix-bot vous indiquant
 que la demande de déploiement pour Pix UI a bien été prise en compte.
@@ -34,33 +35,35 @@ indiquant le numéro de sa nouvelle version.
 Et voilà 🎉
 
 Si vous souhaitez suivre le déroulement de la release, consulter les [logs](https://github.com/1024pix/pix-ui/actions/workflows/deploy-storybook.yml)
-de la  GitHub action `Deploy Pix UI Storybook`.
+de la GitHub action `Deploy Pix UI Storybook`.
 
 ## Constater le bon fonctionnement de la release
 
 Pour vérifier si la release s'est bien déroulée :
+
 - vérifier le contenu du [CHANGELOG.md](../CHANGELOG.md) : contient-il toutes les PR qui ont été mergées récemment sur la branche `dev` ?
 - vérifier si notre [Storybook en ligne](https://1024pix.github.io/pix-ui/) montre bien les nouveaux composants.
 
-
 ## Effectuer la release, méthode à la mano (déconseillée)
+
 Après s'être mis à jour sur la branche dev, lancer le script de publication :
+
 - `git checkout dev`
 - `git pull`
 - `./scripts/publish.sh <version_souhaitée>`
 
   `<version_souhaitée>` peut prendre 3 valeurs :
-    - `patch` : correctif de bug
-    - `minor` : modifications n'apportant pas de changement dans l'utilisation de Pix UI
-    - `major` : modifications apportant des breaking changes
+
+  - `patch` : correctif de bug
+  - `minor` : modifications n'apportant pas de changement dans l'utilisation de Pix UI
+  - `major` : modifications apportant des breaking changes
 
 Pour plus d'informations au sujet de la version à choisir se référencer à [SemVer](https://semver.org/lang/fr/).
 
 Le script de publication effectuera automatiquement les actions suivantes :
+
 - mise à jour de la version du projet dans le `package.json`
 - création d'un tag git correspondant à la nouvelle version
 - mise à jour de la liste des changements dans le [CHANGELOG.md](../CHANGELOG.md)
 - mise à jour de la branche `master` par rapport à `dev`
 - re-[déploiement de storybook sur les GitHub Pages](/?path=/docs/développement-storybook--page)
-
-

package/docs/pix-design-tokens-dev.stories.mdx

@@ -1,4 +1,4 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
 <Meta title="Développement/Pix Design Tokens" />
 

package/docs/storybook.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Développement/Storybook' />
+<Meta title="Développement/Storybook" />
 
 # Déploiement de Storybook
 
@@ -33,10 +33,11 @@ npm run deploy-storybook
 ```
 
 Cette commande fait appel à l'outil [storybook-deployer](https://github.com/storybookjs/storybook-deployer). Ce dernier effectue les actions suivantes :
+
 - compiler Storybook comme une application statique
 - commit et push le résultat précédent sur la branche `gh-pages`
 
-*(Il est possible de customiser l'auteur ou le nom des commits, voir sur la [doc de storybook-deployer](https://github.com/storybookjs/storybook-deployer).)*
+_(Il est possible de customiser l'auteur ou le nom des commits, voir sur la [doc de storybook-deployer](https://github.com/storybookjs/storybook-deployer).)_
 
 Le changement de la branche `gh-pages` est détecté par les Github Pages et la nouvelle version du site est re-déployée.
 

package/docs/test-component-without-release.stories.mdx

@@ -1,4 +1,4 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
 <Meta title="Développement/Tester un composant en developpement dans une app" />
 

package/docs/use-component.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Utiliser Pix UI/Utiliser un composant' />
+<Meta title="Utiliser Pix UI/Utiliser un composant" />
 
 # Utiliser un composant
 
@@ -63,8 +63,8 @@ Si cela ne fonctionne pas, vérifier dans Pix UI que le composant hérite des at
 et que cet argument soit placé en dernier pour qu'il puisse surchager les attributs par défaut du composant.
 
 ```hbs
-<p class="pix-message {{concat "pix-message--" this.type}}" ...attributes>
-   ...
+<p class='pix-message {{concat "pix-message--" this.type}}' ...attributes>
+  ...
 </p>
 ```
 
@@ -74,11 +74,12 @@ L'accessibilité du composant lui-même est déjà testé par Storybook, voir
 [Bonnes Pratiques / Accessibilité](/?path=/docs/développement-bonnes-pratiques-accessibilité--page).
 
 Mais il faut aussi vérifier son accessibilité une fois composant intégré dans l'application front.
-*Par exemple, le libellé étant spécifique à chaque bouton, il doit être défini à l'instanciation.*
+_Par exemple, le libellé étant spécifique à chaque bouton, il doit être défini à l'instanciation._
 
 Pour tester l'accessibilité, on peut utiliser [l'extension Wave](https://wave.webaim.org/extension/) (Chrome et Firefox).
 
 Voici quelques liens utiles :
+
 - https://github.com/1024pix/pix/blob/dev/docs/Accessibilite.md
 - https://1024pix.atlassian.net/wiki/spaces/DEV/pages/2856288297/2021-05-27+-+Compte-rendu+Atelier+accessibilit+Tanaguru+les+devs
 
@@ -86,4 +87,4 @@ Voici quelques liens utiles :
 
 Si une icône n'apparaît pas lorsqu'un composant est instancié, il faut vérifier que l'icône est bien déclarée dans le
 fichier `config/icons.js` de l'application concernée.
-*Par exemple, `PixBanner` utilise l'icône `info-circle`, il faut penser à l'ajouter au fichier `icons.js`.*
+_Par exemple, `PixBanner` utilise l'icône `info-circle`, il faut penser à l'ajouter au fichier `icons.js`._

package/docs/use-install.stories.mdx

@@ -1,6 +1,6 @@
-import { Meta } from '@storybook/addon-docs/blocks';
+import { Meta } from '@storybook/addon-docs';
 
-<Meta title='Utiliser Pix UI/Installation' />
+<Meta title="Utiliser Pix UI/Installation" />
 
 # Installer l'addon Pix UI
 
@@ -8,7 +8,6 @@ Pour installer Pix UI dans une application Ember il suffit d'écrire la commande
 
 `npm install @1024pix/pix-ui@<tag_souhaité>` où `<tag_souhaité>` est la [dernière version](https://github.com/1024pix/pix-ui/tags).
 
-
 # Mise à jour de l'addon Pix UI <a id="Addon"></a>
 
 `npm install @1024pix/pix-ui@<tag_souhaité>`
@@ -19,10 +18,11 @@ ou bien, aller changer dans le `package.json` la version de Pix UI et faire un `
 
 `<tag_souhaité>` doit correspondre au numéro de version à installer. Ce numéro de version correspond à une release.
 
-*Par exemple, on peut remplacer `<tag_souhaité>` par `v0.1.1`.*
+_Par exemple, on peut remplacer `<tag_souhaité>` par `v0.1.1`._
 Pour voir la liste des tags de Pix UI, [c'est par ici.](https://github.com/1024pix/pix-ui/tags)
 
 Selon la convention [Semver](https://semver.org/lang/fr/), un tag est sous le format `vx.y.z`.
+
 - `x` est une version majeure
 - `y` est une version mineure
 - `z` est un patch
@@ -33,5 +33,5 @@ Lorsqu'il y a un changement de version majeure, il faut faire attention aux chan
 
 Pour se mettre au courant des changements majeurs, il faut aller voir dans le [CHANGELOG](https://github.com/1024pix/pix-ui/blob/dev/CHANGELOG.md), pour pouvoir voir chaque PR concernée par la montée de version.
 
-*Par exemple, si l'on souhaite passer de la version v2.2.0 de Pix UI à v3.0.0, on voit dans le CHANGELOG que la PR [#79](https://github.com/1024pix/pix-ui/pull/79) a changé le nom d'un composant.
-Cela implique donc de changer le nom du composant partout dans l'application front où l'on souhaite monter de version.*
+_Par exemple, si l'on souhaite passer de la version v2.2.0 de Pix UI à v3.0.0, on voit dans le CHANGELOG que la PR [#79](https://github.com/1024pix/pix-ui/pull/79) a changé le nom d'un composant.
+Cela implique donc de changer le nom du composant partout dans l'application front où l'on souhaite monter de version._

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@1024pix/pix-ui",
-  "version": "24.1.0",
+  "version": "24.2.1",
   "description": "Pix-UI is the implementation of Pix design principles and guidelines for its products.",
   "keywords": [
     "ember-addon"