@acvl/frontend-components 0.0.90 → 0.0.92

package/dist/index.d.ts

@@ -217,6 +217,7 @@ interface GridArgs {
     ignoreSort?: boolean;
 }
 interface GridColDefPropsOverrides extends GridBaseColDef {
+    /** Lo que el panel de filtros necesita de la columna. La edición en línea no lo lee. */
     extra?: {
         queryArgs?: ComoOpcionesProps;
         options?: {
@@ -224,6 +225,19 @@ interface GridColDefPropsOverrides extends GridBaseColDef {
             label: string;
         }[];
         max?: number;
+        /**
+         * La llave de query que escribe el filtro, en lugar de la que deriva el panel
+         * (`<campo>__in`, o `id__in` para `nombre`). La usa, por ejemplo, una columna que filtra
+         * eligiendo registros sin llamarse `nombre`: el número económico de un tracto.
+         */
+        filterField?: string;
+        /**
+         * El filtro con el que busca el selector del panel al teclear. Es el `searchField` de
+         * `ControlledAutocomplete` y, como ahí, por defecto es `nombre__icontains`. Un modelo sin
+         * `nombre`, o cuyo filterset no lo declara, tiene que dar el suyo (por ejemplo `search`):
+         * django-filter ignora en silencio el parámetro que no conoce, y el tecleo no filtraría.
+         */
+        searchField?: string;
     };
     input?: any;
     filterName?: string;
@@ -2246,6 +2260,11 @@ interface FieldProps {
  * (`renderEditCellWithErrorTooltip` con `mutationErrors`); la ficha, sobre el campo. La columna
  * `codigo` del listado no es filtrable, así que el backend no tiene que atender `codigo__in`.
  *
+ * **Los filtros del recurso aceptan `id__in`.** El listado filtra la columna `nombre` eligiendo
+ * registros, y el panel de filtros manda los ids elegidos como `id__in` —en django-filter,
+ * `"id": ["exact", "in"]`—. Donde no lo atiende, django-filter ignora el parámetro en silencio:
+ * el filtro se ofrece y no hace nada.
+ *
  * Y lo que ya pide cualquier pantalla de la librería:
  *
  * - El listado, paginado con `results` y `count`.
@@ -2257,13 +2276,19 @@ interface FieldProps {
  * - Guardar (POST o PATCH) contesta `{ detail, list }`: `manualCacheRefresh` copia `detail` en la
  *   caché del detalle y `list` en el renglón del listado, sin volver a pedirlos.
  *
- * Y lo que necesita quien lo referencie, aunque ni el listado ni la ficha lo consultan:
+ * Y `como_opciones`, con `{ value, label }` y el id como `value`. De ahí saca sus opciones
+ * cualquier selector que liste el catálogo (`ControlledAutocomplete` con
+ * `queryArgs: { endpoint }`), y ya no sólo los de otros modelos:
  *
- * - `como_opciones`, con `{ value, label }`. De ahí saca sus opciones cualquier selector que
- *   liste el catálogo (`ControlledAutocomplete` con `queryArgs: { endpoint }`): el campo con el
- *   que el formulario de otro modelo lo elige, o la columna que apunta a él en el panel de
- *   filtros de otra grilla. Sin esto el catálogo se administra, pero no se puede elegir desde
- *   ningún lado.
+ * - **el propio listado**, para su filtro por nombre: la columna `nombre` lleva `queryArgs` con
+ *   este `endpoint`, y lo que el usuario elige ahí se manda como `id__in` —por eso el `value`
+ *   tiene que ser el id—;
+ * - el campo con el que el formulario de otro modelo lo elige, o la columna que apunta a él en el
+ *   panel de filtros de otra grilla.
+ *
+ * Al teclear, el selector busca con `nombre__icontains` (su `searchField` por omisión), así que
+ * los filtros del recurso lo aceptan también. Sin `como_opciones` el filtro por nombre del
+ * listado sale vacío y el catálogo no se puede elegir desde ningún otro lado.
  */
 interface DefinicionDeCatalogo {
     /**
@@ -2368,6 +2393,12 @@ declare const crearFabricaDeCatalogos: <BaseQuery extends BaseQueryFn<string | F
  * Un catálogo puede omitir alguna de las de la base con `ocultarColumnas` — quitar, nunca cambiar
  * lo que hacen; ver `DefinicionDeCatalogo`.
  *
+ * `nombre` **se filtra eligiendo registros**. El panel de filtros convierte la columna `nombre`
+ * en `id__in` (`filterFieldFor`): la lista que se manda son ids, no nombres. Por eso lleva
+ * `extra.queryArgs` con el endpoint del catálogo: el selector saca sus opciones del
+ * `como_opciones` de ese mismo recurso, cuyo `value` es el id. Sin `queryArgs` el selector
+ * aparecía vacío. `extra` sólo lo lee el panel de filtros; la edición en línea no lo toca.
+ *
  * `codigo` **no es filtrable**. En el panel de filtros una columna de texto es un selector
  * múltiple que filtra por `<campo>__in`, y el contrato no le pide al backend `codigo__in`: donde
  * no lo atiende —django-filter ignora en silencio el parámetro que no conoce— el filtro se

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@acvl/frontend-components",
-    "version": "0.0.90",
+    "version": "0.0.92",
     "description": "Component library for ACV frontend projects.",
     "homepage": "https://github.com/ACV-Logistics/acv-frontend-components#readme",
     "access": "public",