@acvl/frontend-components 0.0.89 → 0.0.91

package/dist/index.d.ts

@@ -2243,11 +2243,13 @@ interface FieldProps {
  *
  * **La unicidad de `codigo` la garantiza el backend, no la grilla.** Un choque vuelve como un
  * 400 con el error en `codigo`, y la edición en línea lo pinta sobre la celda
- * (`renderEditCellWithErrorTooltip` con `mutationErrors`); la ficha, sobre el campo. El
- * `extra.queryArgs.endpoint` que lleva la columna `codigo` no valida nada: es lo que hace que el
- * panel de filtros la ofrezca como selector múltiple, con las opciones que sirve el
- * `como_opciones` de ese mismo endpoint, y filtre por `codigo__in`. Por eso el recurso también
- * tiene que servir `como_opciones`.
+ * (`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:
  *
@@ -2259,6 +2261,20 @@ interface FieldProps {
  *   borrado que el servidor va a rechazar.
  * - 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 `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:
+ *
+ * - **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 {
     /**
@@ -2363,10 +2379,17 @@ 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`.
  *
- * `codigo` lleva `extra.queryArgs.endpoint`, que es lo que hace que el panel de filtros la
- * ofrezca como selector múltiple con las opciones del propio recurso (`como_opciones`). **No
- * valida la unicidad**: eso lo hace el backend al guardar, y el choque vuelve como el error que
- * `renderEditCellWithErrorTooltip` pinta sobre la celda.
+ * `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
+ * ofrecía y no hacía nada. Tampoco valida la unicidad: eso lo hace el backend al guardar, y el
+ * choque vuelve como el error que `renderEditCellWithErrorTooltip` pinta sobre la celda.
  */
 declare const columnasDeCatalogo: (definicion: DefinicionDeCatalogo) => (props?: EditGridColumnsProps) => GridColDefPropsOverrides[];
 
@@ -2672,6 +2695,9 @@ interface CatalogoListProps {
      * una pestaña hay que pasarla explícitamente: ahí `useLocation()` devuelve la ruta de la
      * página contenedora, así que sin esto los renglones navegarían al detalle de la página que
      * contiene las pestañas y todas ellas compartirían una sola llave de persistencia.
+     *
+     * No decide contra qué recurso se exporta: eso es siempre `definicion.endpoint` (ver
+     * `CatalogoList`).
      */
     pathname?: string;
     /**
@@ -2700,6 +2726,14 @@ interface CatalogoListProps {
  *
  * El alta siempre está —sujeta al permiso de agregar—; la importación CSV sólo si se pasa
  * `csvUpload`.
+ *
+ * **La exportación CSV va siempre contra `definicion.endpoint`.** `ExportCSV` exporta contra el
+ * `csvProps.endpoint` que reciba y, sin él, contra la ruta de la página (`useLocation()`) —a
+ * propósito no contra el `pathname` de la grilla, que también es llave de persistencia y no tiene
+ * por qué ser una URL—. Pero la ruta es de la página, no del recurso: dentro de una pestaña es la
+ * de la página que contiene las pestañas, y la descarga pedía algo que no es el catálogo. El
+ * endpoint es el recurso esté donde esté montado el listado, así que se pasa siempre, igual como
+ * página propia que como pestaña. Lo arma `dataGridPropsDeCatalogo`.
  */
 declare const CatalogoList: ({ definicion, api, pathname, csvUpload }: CatalogoListProps) => react_jsx_runtime.JSX.Element;
 

package/package.json

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