Aggiornamento da 0.18 a 0.21

Aggiornamento 0.18 → 0.21

La 0.21.0 è stata rilasciata. Queste sono le voci ### Breaking della sua sezione del changelog, una alla volta, con ciò che ciascuna ti chiede di modificare. Le versioni 0.19 e 0.20 non dichiarano alcuna breaking change, quindi questo è un singolo passaggio da 0.18 — leggilo prima di passare alla 0.21, non dopo.

Entrambe sono errori di compilazione e non cambi di comportamento silenziosi: la build indica ogni riga da modificare, e il grep sotto ogni sezione le trova prima della build.

---

31. context.client.data non compila più in una callback di collection

RebaseCallContext["client"] ora è RebaseCallbackClient: RebaseClient senza data. Sul lato server quel client è il singleton rebase, che non ha più data a partire dalla versione 0.18, per cui context.client.data.collection(…) compilava e poi generava Cannot read properties of undefined (reading 'collection') a ogni chiamata. Ora è invece un errore di compilazione.

Cosa modificare: esegui le query tramite context.data, l’accessor che le query di una callback avrebbero sempre dovuto utilizzare. Viene eseguito con i privilegi di ciò che ha attivato la callback, sulla transazione stessa della scrittura. La guida alle callback illustra ciò a cui può accedere ciascun accessor presente nel contesto.

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 è ancora disponibile per le callback che devono vedere ciò che può visualizzare un admin. Anche admin.browserCallbacks cambia: la vecchia sintassi funzionava lì, poiché il client del pannello include data, ma smette comunque di compilare allo stesso modo. useRebaseContext().client in un componente React mantiene il suo data.

32. selectedEntities è stato rimosso: una selezione è ora composta da righe o da una query

Una vista di collection ora può selezionare tutte le righe che corrispondono al suo filtro, non solo le righe già caricate, perciò SelectionController non restituisce più un Entity[]. selectionController.selection è un’unione EntitySelection: { type: "entities", entities } per le righe selezionate manualmente, oppure { type: "query", query, excluded, count? } per ogni riga corrispondente a una query, la maggior parte delle quali non è mai stata letta.

Cosa modificare: un’azione personalizzata che legge la selezione la converte in righe tramite resolveSelection da @rebasepro/cms. Restituisce le righe selezionate tutte insieme e legge una selezione basata su query una pagina alla volta — con una callback di avanzamento opzionale — generando un errore anziché restituire un prefisso quando la query corrisponde a più di 20.000 righe.

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

Insieme a questo arrivano tre modifiche minori:

• selectionController.selectedEntities.length → selectionController.selectedCount. È undefined, mai 0, quando viene selezionata ogni riga corrispondente a una query e la collection non può essere conteggiata — gestisci il rendering di questo caso, non assegnargli un valore predefinito.
• setSelectedEntities(prev => …) → setSelection(prev => …), che riceve e restituisce un EntitySelection. setSelectedEntities(rows) con un array funziona ancora.
• La verifica per sapere “se c’è qualcosa di selezionato” è selectionController.hasSelection.

isEntitySelected e toggleEntitySelection rimangono invariati e sono ciò che una casella di controllo per riga dovrebbe continuare a utilizzare. L’esempio delle azioni di collection mostra il pattern completo.