J’ai besoin de votre avis sur un contournement mis en place pour un souci d’UX sur les champs select2 :
J’ai un énuméré multiple en présentation Pillbox avec Edit cell activé.
Si on souhaite choisir plusieurs valeurs d’un coup avec la touche Ctrl, ce n’est pas possible en liste car le saveCell se déclenche et recharge toute la liste.
J’ai donc déplacé le listener de change vers close pour ce type de champ.
Voici mon code (pour un champ précis en attendant votre retour)
let chgFct = $._data($("#field_cdpFinpdtdescCarBrand_id61")[0], "events").change[2].handler;
$._data($("#field_cdpFinpdtdescCarBrand_id61")[0], "events").change.pop();
$("#field_cdpFinpdtdescCarBrand_id61").on('select2:close', chgFct);
Est-ce que cela vous semble viable ? J’ai l’impression que c’est bancal car si l’ordre des event change évolue, je risque de supprimer n’importe quoi.
Auriez-vous une solution plus propre en tête ?
Une des solutions socle serait, pour les énum multiples en edit-cell, de ne pas fermer le dropdown à chaque sélection d’option. C’est donc la fermeture du dropdown (click en dehors) qui déclenchera le save du champ.
La modification est déjà poussée en v7, je vais voir si c’est backportable en 6.3
De mon point de vue (qui vaut ce qu’il vaut !) c’est plus intuitif de devoir utiliser CTRL pour garder ouvert. Ou alors proposer un bouton “Apply” comme dans Excel quand on fait des filtres.
Quoi qu’il en soit je suis preneuse de la solution à venir.
Est-ce que mon contournement te paraît risqué en attendant ?
Je viens de voir dans la doc de select2 que lorsque la touche Ctrl est appuyée, le dropdown ne devrait pas se fermer lors de la sélection d’une option. Côté socle il suffit juste de binder le change du field à la fermeture du dropdown.
Ceci étant dit, la touche Ctrl n’étant pas correctement gérée dans le cas d’un champ en edit cell, à mon avis il s’agit plutôt d’un bug qu’une évol et il faudrait backporter le fix.
Concernant ton contournement, je ne maitrise pas suffisamment la call stack pour répondre, je laisse @Francois donner son avis.
Oui je confirme, le CTRL fonctionne correctement, sauf quand on est en Edit cell, parce que ça appelle un reload en cas d’event “change”. Et même si on a CTRL actif, la pillbox s’ajoute en arrière plan et ça déclenche le “change”.
Merci alors le voici : il faudrait effectivement que le trigger du change arrive quand l’utilisateur a terminé sa sélection multiple. En terme d’UX/Accessibilité, il faudra voir si on peut mettre un bouton explicite “Apply” focusable, ou alors binder la touche “Enter”, en plus du “blur/click outside” moins intuitif.
Les champs en Edit-cell doivent rester en “auto-save” au change du champ. Cela force un reload de la liste, ce qui n’est pas toujours souhaitable mais Simplicité ne peut pas savoir les impacts de cette mise à jour sur la liste, les sommes, tris/filtres, etc.)
JQuery déconseille fortement de modifier ses données internes qui peuvent changer dans une prochaine version / sans documentation.
il faut donc plutôt en rester à des ordres simples tels que off("change") ou on("change", e => { e.preventDefault(); e.stopImmediatePropagation(); ... }) pour annuler/stopper des events déjà chargés.
Et il faut éviter d’accéder aux champs par leur $('#id'), mais plutôt passer par une recherche fonctionnelle indépendante de l’implémentation front : $ui.getUIField(ctn, obj, field, index).ui.input qui cherchent le champ dans le container passé à chaque API. En V7, on pourra avoir plusieurs zones de travail pour un même objet/plusieurs records, donc plusieurs inputs d’un même champ avec chacun des DOM ID différents.
Merci de vos retours, d’accord donc je ne peux pas laisser en l’état, je m’en doutais un peu
(pour les #ID, c’était juste pour un essai, j’ai généralisé depuis)
Le souci est que la pillbox s’ajoute à chaque clic même si on a Ctrl maintenu et ça déclenche le “change”. Peut-être y a-t-il un moyen de n’ajouter les pillbox que quand on lâche Ctrl ?
Ca je pense qu’avec un peu d’accompagnement au début, ça peut être compris par les utilisateurs. De toutes façons il faut déjà qu’on explique l’usage du Ctrl.
[EDIT] Je n’ai pas utilisé le off/on car je veux garder les event change de bootstrap, mais un quickfix pour mon contournement serait d’ajouter un namespace à l’event change lié au editCell, ça serait possible ?
f.ui.change( (_, m) => {
if (m != "populate" || f.refId)
saveCell(f);
}
);
Oui c’est l’idée mais cela oblige à faire une évolution, on est en train de revoir les triggers déclenchés par Select2 pour forcer le change que sur CTRL keyup.
Oui ça reste le fonctionnement standard du composant Select2, il faut éviter de le modifier, sinon autant changer de composant.
Oui tu as bien trouvé là où il manque un contexte, mais je ne vois pas de contournement, il va falloir faire une évolution de notre côté.
De plus, on a trouvé un autre soucis sur le bouton “clear” / désélection multiple qui provoque N changes donc N updates, il ne faudrait ne faire qu’une mise à jour à vide. Ca doit aussi pouvoir être surchargé.
On va améliorer ce composant en V7 et quand ce sera ok, on backportera en V6.
Merci de nous aider à qualifier ces composants dans des usages poussés, étant donné le nombre de points de fonction à paramétrer/tester quasi illimité.
Ce sera poussé en 6.3.7.
Click : select/unselect d’un item + change => auto-save edit-cell
Ctrl+click :
select/unselect N items : trigger des change partiels/avec un context particulier select-multi pour ne pas faire d’auto-save en edit-cell
keyup pour déclencher le change final sans context = auto-save de l’edit-cell
On n’a pas pu tout améliorer surtout au niveau RGAA où le focus/sélection via ArrowKey + Enter reste unitaire. Par contre le bouton x d’une pillbox pour retirer un enum sera désormais accessible au clavier, il ne l’était pas.
Il te faudra mettre une aide sur ce champ pour expliquer l’usage du Ctrl.
