Mise à niveau de 0.18 vers 0.21

Mise à niveau 0.18 → 0.21

La 0.21.0 est publiée. Voici les entrées ### Breaking de sa section du changelog, une par une, avec ce que chacune vous demande de modifier. Les versions 0.19 et 0.20 ne déclarent aucun changement cassant, il s’agit donc d’un saut direct depuis la 0.18 — lisez ceci avant de passer à la 0.21, pas après.

Les deux sont des erreurs de compilation et non des changements de comportement silencieux : le build signale chaque ligne à modifier, et le grep de chaque section les trouve avant lui.

---

31. context.client.data ne compile plus dans un callback de collection

RebaseCallContext["client"] est désormais RebaseCallbackClient : RebaseClient sans data. Côté serveur, ce client est le singleton rebase, qui n’a plus de data depuis la version 0.18, donc context.client.data.collection(…) compilait puis levait Cannot read properties of undefined (reading 'collection') à chaque appel. C’est désormais une erreur de compilation.

Ce qu’il faut changer : effectuez vos requêtes via context.data, l’accesseur que les requêtes d’un callback ont toujours été censées utiliser. Il s’exécute avec les privilèges de l’élément ayant déclenché le callback, sur la transaction d’écriture elle-même. Le guide des callbacks détaille ce à quoi chaque accesseur du contexte peut accéder.

afterSave: async ({ context }) => {
    await context.client.data.audit_logs.create({ action: "approved" });
    await context.data.audit_logs.create({ action: "approved" });
}

grep -rn "client\.data\b" config

context.client.dataAsAdmin est toujours disponible pour un callback qui doit voir ce qu’un administrateur peut voir. admin.browserCallbacks change également : l’ancienne syntaxe fonctionnait ici car le client du panneau transporte data, et cela cesse également de compiler. useRebaseContext().client dans un composant React conserve son data.

32. selectedEntities a disparu : une sélection correspond à des lignes ou à une requête

Une vue de collection peut désormais sélectionner chaque ligne correspondant à son filtre, et pas seulement les lignes qu’elle a chargées ; SelectionController ne renvoie donc plus un Entity[]. selectionController.selection est une union EntitySelection : { type: "entities", entities } pour les lignes cochées manuellement, ou { type: "query", query, excluded, count? } pour chaque ligne correspondant à une requête, dont la plupart n’ont été lues par personne.

Ce qu’il faut changer : une action personnalisée qui lit la sélection la transforme en lignes à l’aide de resolveSelection de @rebasepro/cms. Elle retourne immédiatement les lignes cochées et lit une sélection de requête page par page — avec un callback de progression facultatif — en levant une erreur plutôt qu’en retournant un préfixe lorsque la requête correspond à plus de 20 000 lignes.

const handlePublish = async () => {
    for (const entity of selectionController.selectedEntities) {
    const selected = await resolveSelection({
        selection: selectionController.selection,
        accessor: data.collection(path)
    });
    for (const entity of selected) {
        await data.collection(entity.path).update(entity.id, { status: "published" });
    }
};

grep -rn "selectedEntities" config frontend

Trois ajustements mineurs l’accompagnent :

• selectionController.selectedEntities.length → selectionController.selectedCount. Il vaut undefined, jamais 0, lorsque chaque ligne correspondant à une requête est sélectionnée et que la collection ne peut pas être comptée — gérez ce cas au rendu, ne lui attribuez pas de valeur par défaut.
• setSelectedEntities(prev => …) → setSelection(prev => …), qui reçoit et retourne une EntitySelection. setSelectedEntities(rows) avec un tableau fonctionne toujours.
• La vérification pour savoir si « quelque chose est sélectionné » se fait via selectionController.hasSelection.

isEntitySelected et toggleEntitySelection restent inchangés et sont ce qu’une case à cocher par ligne doit continuer d’utiliser. L’exemple d’actions de collection illustre l’ensemble du modèle.