Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for v1.0 remake #6

Open
Schlipak opened this issue Oct 27, 2022 · 1 comment
Open

Roadmap for v1.0 remake #6

Schlipak opened this issue Oct 27, 2022 · 1 comment
Assignees
Labels
enhancement New feature or request roadmap:v1.0

Comments

@Schlipak
Copy link
Member

Schlipak commented Oct 27, 2022

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

@Schlipak Schlipak added enhancement New feature or request roadmap:v1.0 labels Oct 27, 2022
@Schlipak Schlipak self-assigned this Oct 27, 2022
@Schlipak Schlipak pinned this issue Oct 27, 2022
@Schlipak
Copy link
Member Author

Schlipak commented Oct 30, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request roadmap:v1.0
Projects
None yet
Development

No branches or pull requests

1 participant