optimajet/formengine

1. This repository is a monorepo for FormEngine, split into a free/community codebase and a premium/examples codebase. The architectural center is a JSON-driven form runtime: form structure is described in JSON or generated from code, then rendered through a viewer/runtime plus a UI theme package.

2. The community/src/packages/core package is the main engine. It contains the form viewer runtime, form JSON builder, validation, localization, event handling, modal/repeater/template support, and the internal state/store layer. If you are diagramming the system, this is the hub that coordinates data, UI metadata, validation rules, and emitted actions.

3. The core runtime is intentionally UI-agnostic. It exposes abstract component definitions and a viewer API, but delegates actual controls to theme/view packages. The main data flow is: form definition in JSON or builder output -> core store/model -> viewer render tree -> component-specific props/events/validation -> user interaction back into store/actions.

4. The community/src/packages/views/* packages are the concrete UI adapters. There are separate packages for Mantine, Material UI, RSuite, and Uploader, each implementing component definitions, wrappers, localized descriptions, and theme-specific behaviors. These packages map core abstractions like buttons, inputs, dialogs, and containers onto each design system.

5. The view packages also define the “catalog” of supported components for each theme. That means the architecture has a clear boundary between engine and presentation: core owns semantics and runtime behavior, while views own component bindings, styling, and theme-specific props.

6. JSON schema generation is a separate subsystem. Packages like json-schema-generator and the per-theme public/schemas/*.json assets produce schema files for forms and component definitions. These are used by tooling, validation, and example apps to load or author forms consistently without coupling to runtime internals.

7. Localization is built into both core and view packages. Core ships language resources and a Fluent-based localization engine, while each theme package supplies its own UI text and component descriptions. In the runtime, localization is part of the rendering layer rather than an external concern.

8. Validation is another first-class pipeline. The core validation subsystem supports schema-driven validation rules, Zod integration, custom rules, and error rendering. Validation results flow back into the viewer/store so components can display field-level errors and control submission or custom actions.

9. The repository also contains example applications that demonstrate end-to-end consumption paths. Community examples include example-viewer, formdata, bundle-size, and a small file-upload server; these show how the core/view packages are embedded in real apps, how form JSON is loaded, and how file upload or bundle analysis is handled around the engine.

10. The community/examples/bundle-size area is a benchmarking harness, not a product feature. It compares different stacks and themes through separate mini-apps, plus build/report scripts that measure JS/CSS output and generate console/CSV/HTML/MDX/JSON reports. This subsystem is useful for architecture because it shows the library’s modular packaging and build boundaries.

11. The premium/examples tree demonstrates the commercial designer workflow and framework integrations. It includes separate example apps for React/Formik, Angular forms, Next.js, and Remix, all reusing shared JSON form definitions and validators. This shows the same core form model being adapted into different host frameworks and rendering environments.

12. Build and packaging are organized per package with Vite/TypeScript configs and package-local publish settings. The repo is structured as independently buildable packages rather than one monolith, which matters for architecture diagrams: each package has its own entrypoints, public assets, and schema artifacts, while the shared runtime contracts come from core.