Carmen Labs

Overview

What a Mutated View is and the model it's built on.

Overview

A Mutated View (MView) is a re-executable, alternate representation of a file. It does not modify the original file — it produces a separate, persistent artifact that can be re-run whenever the source changes.

source file
   │
   ▼
 parser
   │
   ▼
data model
   │
   ▼
view component
   │
   ▼
rendered view

The view updates by re-running the parser against the current file, not by editing anything in place. This is the core invariant of the spec: the source file is read-only from the MView's perspective.

What an MView is made of

An MView is a small bundle of files:

  • mview.json — the manifest. Identity, versioning, capabilities required, and where to find the parser and component. See the Schema Reference.
  • A parser module — transforms normalized input into a data model. See the Parser Contract.
  • A view component — renders that data model with the renderer declared by runtime (for example React, Solid, HTML, PDF, or a custom renderer). See the Component Contract.
  • resources/ (optional) — static assets the component needs (CSS, icons, sample data).

Two placements are valid. Colocated, next to the source file:

sales.csv
.mviews/
└── sales-dashboard/
    ├── mview.json
    ├── parser.ts
    ├── Dashboard.tsx
    └── resources/

Or centralized in a project-level folder, with source.path pointing back at the file:

.mviews/
└── sales-dashboard/
    ├── mview.json
    ├── parser.ts
    ├── Dashboard.tsx
    └── resources/

See Directory Layout for the full discovery convention.

Design invariants

These hold regardless of implementation:

  1. The MView never modifies the source file.
  2. The parser is a pure transform: same input in, same data model out. No filesystem access, no absolute paths.
  3. The component only renders the data model it's given. It does not read files itself.
  4. The runtime — not the parser, not the component — owns file I/O.
  5. Manifests are validated against the published JSON Schema before being loaded or saved.

Next

Descripción general

Qué es una Mutated View y el modelo sobre el que se construye.

Descripción general

Una Mutated View (MView) es una representación alternativa y reejecutable de un archivo. No modifica el archivo original: produce un artefacto separado y persistente que puede volver a ejecutarse cada vez que cambia la fuente.

archivo fuente
   │
   ▼
 parser
   │
   ▼
modelo de datos
   │
   ▼
componente de vista
   │
   ▼
vista renderizada

La vista se actualiza volviendo a ejecutar el parser sobre el archivo actual, no editando nada en el lugar. Esta es la invariante central de la especificación: desde la perspectiva de la MView, el archivo fuente es de solo lectura.

De qué se compone una MView

Una MView es un pequeño paquete de archivos:

  • mview.json — el manifiesto. Identidad, versionado, capacidades requeridas y dónde encontrar el parser y el componente. Ver Referencia del esquema.
  • Un módulo parser — transforma la entrada normalizada en un modelo de datos. Ver Contrato del parser.
  • Un componente de vista — renderiza ese modelo de datos con el renderer declarado por runtime (por ejemplo React, Solid, HTML, PDF o un renderer propio). Ver Contrato del componente.
  • resources/ (opcional) — assets estáticos que necesita el componente (CSS, iconos, datos de ejemplo).

Estructura recomendada

Hay dos ubicaciones válidas. Colocada junto al archivo fuente:

sales.csv
.mviews/
└── sales-dashboard/
    ├── mview.json
    ├── parser.ts
    ├── Dashboard.tsx
    └── resources/

O centralizada en una carpeta a nivel de proyecto, con source.path apuntando de vuelta al archivo:

.mviews/
└── sales-dashboard/
    ├── mview.json
    ├── parser.ts
    ├── Dashboard.tsx
    └── resources/

Ver Estructura de directorios para la convención completa de descubrimiento.

Invariantes de diseño

Se cumplen independientemente de la implementación:

  1. La MView nunca modifica el archivo fuente.
  2. El parser es una transformación pura: misma entrada, mismo modelo de datos. Sin acceso al filesystem, sin rutas absolutas.
  3. El componente solo renderiza el modelo de datos que recibe. No lee archivos por su cuenta.
  4. El runtime, no el parser ni el componente, es dueño de la E/S de archivos.
  5. Los manifiestos se validan contra el JSON Schema publicado antes de cargarse o guardarse.

Siguiente