Notes for the v1.0 roadmap

Form structure format

Rework a standardized versioned format, write an RFC. It will probably not be compatible with the current beta format.

Front-end

Field IDs should include a sequential part to make sure that no duplicate IDs are generated.
Sequential forms should prefix all IDs with an index, so that two instances of the same form can appear in a page without interference (label for attributes and radio/checkbox groups would be affected)
Add builtin basic CSS styles (should be toggleable in the backend)
Maybe consider adding themes that can be selected in the form or plugin settings
Add front-end field validation + support for back-end validation display

Back-end

Add optional back-end field validation (can be configured per form and/or per field)
- AJAX form submission must support detailed validation error responses
Add automatic support for WPML (currently, the plugin can work with WPML if the mvpf-form custom post type is manually set to "translate" in the settings. However, form IDs are not automatically translated by the plugin and must be done by the user)
Consider support for Polylang too
Add a better template override system: same as woocommerce, check if the file exists in the active theme, else use the builtin one.
- Additionally, add better actions and/or filters to override a specific template.

Admin UI

Rework the entire UI inside a single React app, with MobX-backed state.

Enhanced form structure editor, not based on rows but on a grid (to be rendered with CSS grids using grid-column and grid-row)
Add a breakpoint system to allow users to specify a different fields layout at specific breakpoints (reorder / resize fields and save their new rect)
Rework the field settings UI to prevent having to scroll back up when editing a field at the bottom of the form. Decouple the field data and the settings structure, so that any update doesn't depend on the saved field data and can then convert the JSON data to the newer format.
Synchronize field and form settings with the MobX state for easier settings edition (ex: conditional email based on a select field)
Hide select options value attribute from the settings editor: the value does not matter, as it's only used internally, and showing it makes the settings editor more complex than it should be. Optionally allow to edit them if the user choses so. Otherwise, generate a unique ID.
Dependent fields: set field as mandatory or not, or show/hide field depending on other field values.
- This could allow to hide a select with a set of options and show another depending on a checked value. However, the grid system wouldn't allow two fields from being displayed in the same grid cell. Possible solution: Create a "dependent group" field type that would contain the two conditional select fields.
Optional "technical ID" setting to allow getting a specific field from code without relying on the auto-generated UUID or the title (which can be updated or translated by the user, breaking the code).

Useful links

Grid layout: https://github.com/react-grid-layout/react-grid-layout
Media query hook (and others that could be useful too) : https://usehooks-ts.com/react-hook/use-media-query

Notes on the new JSON format

Draft for the new JSON format

{
  "version": "1.0.0",
  "form_id": "WORDPRESS_POST_ID",
  "fields": [],
}

Field data should follow a similar structure structure :

{
  "type": "FIELD_TYPE_IDENTIFIER",
  "id": "FIELD_UUID",
  "rect": {
    "default": { "x": 0, "y": 0, "w": 1, "h": 1 },
    "breakpoints": [
        { "above": "@media min-width", "below": "@media max-width", "x": 0, "y": 0, "w": 1, "h": 1 },
        { "above": "@media min-width", "below": "@media max-width", "x": 0, "y": 0, "w": 1, "h": 1 },
    ]
  },
  "properties": { "...FIELD_SETTINGS" }
}

Dependent group field :

{
  "type": "dependent_group",
  "id": "FIELD_UUID",
  "rect": { "...FIELD_RECT" },
  "children": [ "...FIELDS_WITHOUT_RECT" ]
}

Dependent field:

{
  "...FIELD_STRUCT",
  "dependent": {
    "enabled": true,
    "predicate": [
      // OR conditions
      {
        // AND conditions
        "conditions": [
          { "field": "FIELD_ID", "operator": "equals", "value": "..." },
          { "field": "FIELD_ID", "operator": "not equals", "value": "..." },
          { "field": "FIELD_ID", "operator": "contains", "value": "..." },
          { "field": "FIELD_ID", "operator": "not contains", "value": "..." },
          { "field": "FIELD_ID", "operator": "like", "value": "..." },
          { "field": "FIELD_ID", "operator": "not like", "value": "..." }
        ]
      },
      {
        "conditions": ["..."]
      }
    ]
  }
}

→ Maintain a separate parser implementation for each breaking change version for the JSON to internal object representation conversion.

mashvp / mashvp-forms

Roadmap for v1.0 remake #6