|
| 1 | +## JSON Forms Project information |
| 2 | + |
| 3 | +JSON Forms is a declarative framework for efficiently building form-based web UIs. |
| 4 | +These UIs are targeted at entering, modifying and viewing data and are usually embedded within an application. |
| 5 | + |
| 6 | +Any UI is defined by using two schemata: |
| 7 | + - The JSON schema defines the underlying data to be shown in the UI (objects, properties, and their types) |
| 8 | + - The UI schema defines how this data is rendered as a form, e.g. the order of controls, their visibility, and the layout. |
| 9 | + If no UI schema is given, JSON Forms generates one based on the given JSON schema. |
| 10 | + |
| 11 | +We put great emphasis on the customizability and extensibility of JSON Forms. |
| 12 | + |
| 13 | +### Architecture overview |
| 14 | + |
| 15 | +The JSON Forms mono repository consists of these packages: |
| 16 | + - `@jsonforms/core` in `packages/core`: Provides utilities for managing and rendering JSON Schema based forms. |
| 17 | + The core package is independent of any UI technology. |
| 18 | + - `@jsonforms/react` in `packages/react`, `@jsonforms/angular` in `packages/angular`, `@jsonforms/vue` in `packages/vue`. |
| 19 | + These use the core package to provide specialized bindings for React, Angular and Vue, leveraging each respective's state management and rendering systems. |
| 20 | + - For React we maintain two renderer sets: The `@jsonforms/material-renderers` in `packages/material-renderers`, which are based on the popular Material-UI framework and `@jsonforms/vanilla-renderers` in `packages/vanilla-renderers` which provides pure HTML5 renderers. |
| 21 | + For Angular we provide an Angular Material based renderer set (`@jsonforms/angular-material` in `packages/angular-material`). For Vue we provide a HTML5 based renderer set `@jsonforms/vue-vanilla` in `packages/vue-vanilla` and a Vuetify based one `@jsonforms/vue-vuetify` in `packages/vue-vuetify`. |
| 22 | + |
| 23 | +### Mono-repo Setup |
| 24 | + |
| 25 | +- Package Manager: pnpm with lerna for orchestration |
| 26 | +- Dependency Management: Each package declares all its dependencies explicitly (no hoisting assumptions). We aim to use the same dependency versions across packages (e.g. for Typescript or Jest) |
| 27 | +- Testing: Independent test setup per package. Tests are implemented in separate folder `test` or `tests` within a package. |
| 28 | +- Build: Each package has its own build configuration. Rollup is the default tool except if there are other typical tools for the respective technology (e.g. Angular) |
| 29 | +- Linting and Formatting: Each package has its own `.eslintrc.js` and `.prettierrc.js` config |
| 30 | +- Typescript: Packages extend common base config `tsconfig.base.js` |
| 31 | + |
| 32 | +### Core principles |
| 33 | + |
| 34 | +JSON Forms uses a reducer-style approach for its state management. |
| 35 | +The form-wide state is manipulated via the reducers in `packages/core/src/reducers`. |
| 36 | + |
| 37 | +Renderers are registered in a registry, consisting of tester, renderer pairs. |
| 38 | +For each UI Schema element to be rendered, all testers are asked for their priority. |
| 39 | +The highest priority wins and the respective renderer gets full control over rendering. |
| 40 | +The renderer may dispatch back to JSON Forms to render children elements. |
| 41 | + |
| 42 | +Dispatchers only receive a minimal amount of properties, e.g. which part of the JSON Schema they are refering to and which UI Schema element is to be rendered. |
| 43 | +Mappers in packages/core/src/mappers are then used to determine the actual props for the renderers to work with, combining the handed over dispatch props and the form-wide state. |
| 44 | + |
| 45 | +The binding packages `@jsonforms/react`, `@jsonforms/angular` and `@jsonforms/vue` bind these functionalities to mechanisms of their respective framework. |
| 46 | +The renderers then use the bound functionalities and usually do not interact with `@jsonforms/core` directly. |
| 47 | + |
| 48 | +### Coding Guidelines |
| 49 | + |
| 50 | +When creating new functions we prefer the arrow style approach |
| 51 | + |
| 52 | +### Development Guidelines |
| 53 | + |
| 54 | +The framework is popular, therefore we never break adopters if we don't have to. |
| 55 | +Consider this for all changes. |
0 commit comments