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.

Sign up for GitHub

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

Jump to bottom

Requirements gathering for Dynamic forms #1447

Open
DutchBen opened this issue Sep 19, 2024 · 4 comments
Open

Requirements gathering for Dynamic forms #1447

DutchBen opened this issue Sep 19, 2024 · 4 comments
Labels
frontend

Comments

@DutchBen
Copy link
Collaborator

DutchBen commented Sep 19, 2024 •
edited
Loading

Get a list of requirements and ideas related to dynamic forms. This list will be used to compare with NCSC to see if there is enough common ground to create a separate open source project.
Requirements include

  • What are all the fields we need
  • What are all the use cases for fields that depend on each other
  • What are cases for configurable layouts
@DutchBen
Copy link
Collaborator Author

DutchBen commented Oct 9, 2024 •
edited
Loading

RFC 1:
dynamicForms-requirements.txt

@DutchBen
Copy link
Collaborator Author

DutchBen commented Oct 9, 2024 •
edited
Loading

Dynamic Forms requirements

This document describes the minimum functionality SURF needs from a forms library. The goal of the
library is to transform a model that is defined on the backend as required input for a workflow into
a react form on the frontend. We are looking at the possibility to share this functionality as an open source
package so it can be used in contexts outside of SURF.

The package has 2 parts. The backend part that generates a JSONSchema and a frontend part that converts the schema into
a html form

Frontend

Current frontend package

The current package we use is based on Uniforms. Uniforms handles the transformation from JSON to form fields. We have
a list of basic fields, some wfo specific fields and some fields that implement very specific Surf logic.

The basic fields are:

The orchestrator core specific fields are:

The WFO Surf specific fields are:

Some fields depend on retrieving data after the field is loaded by making data calls. The SubscriptionField depends both
on retrieving data and on the params passed to it in the form defintion.

Future frontend package

For a future package we propose:

  • Implemtation of all basic fields
  • Implement a way to add custom fields
  • Implement a validation callback that can be called on every field value change. The return value from this call can be used to update the form defintion with data that can be used in other fields. We want to see if this way we can move all data retrieval to the backend
  • Have the complete form state available in all fields

Open issues: Layout customization

Backend

... tbi ...

@Mark90
Copy link
Contributor

Mark90 commented Oct 9, 2024 •
edited
Loading

Extending on this (note that this was a very rough idea without any certainty that it may work)

Implement a validation callback that can be called on every field value change. The return value from this call can be used to update the form defintion with data that can be used in other fields. We want to see if this way we can move all data retrieval to the backend

The "validation callback" here means doing the same POST call with form data that would be done on submit, but then upon changing a field (which could/should be restricted to fields of certain type, because this call may not be very fast if you are at formpage 10 for example) - or when pressing the 'reload' button near dropdowns (i.e. SubscriptionField).

This call would need to set a parameter in the body (validate_only: true or something) so that the pydantic-forms formgenerator only performs validations up until the last supplied formpage (perhaps without returning a "FormNotCompleteError" if the form is indeed valid, but maybe that doesn't matter)

We want to see if this way we can move all data retrieval to the backend

This obviously needs considerable changes to the backend forms and probably to the frontend components as well.
The backend formpages would have to fetch all data needed for the dropdown, in a performant way.

The idea is that for dropdowns of which selecting a value has consequences for other fields,when a user selects a dropdown value, this will trigger the validation_only call so that the dependent field can be populated/enriched after calling the backend. For example in case of Surf's SubscriptionField; when selecting a subscription in the dropdown, currently the UI loads available vlans from IMS and adds them in the subtext of the vlan inputfield. In the proposed new situation, the subscription_id would be supplied as input to the backend call, which could somehow do this IMS call. (I'm not completely sure yet how this would work in the FormPage model though..)

2 challenges with that would be:

  1. How to use this in list fields? I.e. a field that a user can add/delete subscription rows from in the frontend
  2. Will this be performant enough? As I mentioned before, if you have a long workflow with 10+ pages then all of the pages are validated on each call. So it may take relatively long for the validate_only call to complete

@DutchBen
Copy link
Collaborator Author

Meeting notes - 16-10

Ruben, Wouter, Mark, Tjeerd

Building on what was discussed and summarised above these considerations were added

  • Does the validation callback need to do a full validation every call or are there shortcuts we can make to limit it only to things relevant for the default values needed for populating fields.
  • Using the validation callback has the potential to solve the need to add surf specific frontend code in a lot of components. We still want to be able to add completely customised fields. Both to allow for a smooth transition from one form solution to the next and to make very specific cases possible that we might nog have thought off.
  • The best next step is to create a poc to see if we can get it to work like envisioned

Regarding configurable layourts whe have discussed

  • When building the frontend app care should be taken that presentation and logic are separated so we can make different implementations of the presentation so you can switch between display types (like: https://uniforms.tools/docs/tutorials-customizing-your-form-layout/).
  • For the layout of a form there are 2 options:
    -- Leave it completely to the frontend. This gives little control over how a specific field is displayed
    -- Use a grid system and and add a columns property to the form field definition that determines how many columns a field should take up in the grid.

Possible next steps:

  • Create tickets to make a poc
  • Compare notes with @acidjunk and team

@wouter1975 wouter1975 mentioned this issue Nov 28, 2024
Closed
This was referenced Jan 14, 2025
Closed
Closed
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
frontend
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@DutchBen @Mark90 @hanstrompert