Form

Interactive web form ⌨️

Component demo​

Purposes of the component

Component Settings sections

  • ​General. Settings like header, description, buttons text, etc.

  • ​Fields. Configuring inputs for form fields.

  • ​Result. On-line submission processing.

General form settings

  • ​API-endpoint. That defines the fields available for writing.

  • Form title;

  • Form description (you can use Markdown here);

  • Submit button text (Submit by default);

  • Re-submit button text (Submit again by default);

  • Labels or placeholders. Switches the view of inputsβ€”field names can be displayed above the field or as a placeholder;

Labels (on the left), Placeholders (on the right)
  • Form max width in pixels.

Fields settings

Each field (available for writingβ€”POST-requesting in API-endpoint) has a specific data type. You can find configure the form input field, according to the field type.

Sections

You can display sections as sections or just invisible groups (useful for conditional sections):

Display as a section is ON on the left screen

Conditional sections

Visibility of a section can depend on the user's choice of fields values above

In this example the "Section 2" is visible if only the user choses value "bug" for the field {{feature_type}}

If the option Quick search is ON (it is by default), objects from the linked structure will be displayed as options in selects (the visible name will be displayed, if there is no such, the id field will be displayed). Max quantity of options is 1000.

Hidden fields

If you marked field as a hidden one (that is possible for string and link fields), they will be get from URL query params. That looks like (fieldOne and fieldTwo are hidden fields):

yourapp.directual.app/FormPage?fieldOne=value&fieldTwo=1984

Query params have to start with ? and be separated by &

Here we will get in the submitted object:

fieldOne = value

fieldTwo = 1984

Personalisation

You can include hidden field for User ID, which will be filled automatically if the user is logged in.

First, you need to have a field type of link to WebUser data structure available for posing in your API-endpoint.

Find section in Personalisation section in Fields settings:

The user's ID will be posted in this field automatically. If the user isn't logged in, the field will be empty.

Remember, that you can configure your API-endpoint in a way, when unauthorised user will not be able to submit the form.

Editing existing objects

If you want to edit existing object plus to creating new you can turn on that option in Fields settings section:

Don't forget to add id field in API-endpoint available both for writing and reading. Also you must add all the fields you want to be fetched available for reading in API-endpoint settings. Keep id be included into the form, but hidden β€” this is settings by default.

There are two ways to get id of the object to edit:

  1. From query param @editObject=_id_ form URL, where_id_ is id of the object you would like to edit.

  2. Use user's id as an id of object to edit. You could edit App user (WebUser) object that way. Also any other object with such an id.

Online result processing

Submitted object can be processed in sync scenario, and then the result is to be displayed to the user. There three fields of the object for interpreting the result of object processing:

  • Result: success/fail. Boolean field. If the field is true, the Success block is showed. If that field is false, the error block is showed.

  • Result message title. String field. The title of the result block.

  • Result message text. String field. The text of the result block.

Remember, that object is saved despite of the result of sync processing. But if object does not match validation rules, it is not saved!

Hint: you can build an online calculator for your app on that form with a sync result processing.