Best Practices: JavaScript in Forms

There are multiple methods for using JavaScript with Kinetic Forms. There are pros and cons to each of these methods, and you may find that the ideal solution uses a combination of each.

JavaScript in Forms

Placing JavaScript in forms has these general advantages:

• Anyone working on a form can view and update the JavaScript
• Functions can be specific to the form
• When functions are edited, there is no need to regression test other forms
• React libraries loaded into the bundle are not available to forms. If the React library's functionality is also required in a form, you would have to load an additional non-React JavaScript library with that functionality.

Placing JavaScript in forms has these general disadvantages:

• Code may be duplicated and additional maintenance may be required if the same function is needed across more than one form.
• Out of the box exports for Kinetic Forms compress events into a single line, making updates hard to read or diff in a code repository.

There are two primary ways of handing JavaScript in a form:

• Placing the JavaScript in a form load event
• Placing the JavaScript in the event where it is used

JavaScript in a Load Event

Placing the JavaScript for a form into a load event

• Allows the functions to be ready immediately upon form load.
• Allows, when properly scoped, the functions to be available to all other events run on the form.
• Allows all of the functions to be placed together as if it were one js load file for the form.

As mentioned in the points above, using this load event method does require that functions be properly scoped. If a function is defined as:

function buildTables() {
    //Build the items table from the indicated stored JSON
    buildSegmentTable('segmentTableJSON', 'segments');
}

This function buildTables() will not be available outside of the event where it is defined. However, if one sets up the bundle to contain a function called bundle.helpers (for example) then a developer could set up something like this:

bundle.helpers.myform = bundle.helper.myform || {};
bundle.helpers.myform.buildTables = function () {
    //Build the items table from the indicated stored JSON
    buildSegmentTable('segmentTableJSON', 'segments');
}

Then bundle.helpers.myform.buildTables() will be available throughout the form’s events.

Another potential disadvantage is that the functions will be defined in the load event rather than in the event(s) in which they are used, causing the developer to have to potentially have to hop between events to make updates.

JavaScript in the Event Where it is Used

Placing the JavaScript in the event where it is used

• Allows use of JavaScript functions without any need for scoping
• Allows the function to be right there in the place where it is used, providing the simplest possible access to the code for developers.

Unfortunately, the code may need to be duplicated in the same form due to a lack of scoping. This could lead to additional maintenance work or functions named the same that have slightly different behavior in different events.

Of course, functions anywhere can be scoped. Scoping functions defined throughout the form can lead to a hunt the function process for developers in charge of maintaining the code. Likely a function was scoped because it is called in more than one place, and there could be issues later with it being called before it is defined (since it isn’t being defined on load).

There are definitely use cases that can and do work in this scenario, but they are limited.

Methods to avoid

The following two methods are not advised because of unpredictability:

• Placing the JavaScript in the Form's advanced header content
• Placing the JavaScript in an HTML element on the Form

These both depend on the timing of those particular elements being loaded for the JavaScript to be run and/or to be available. Given that the Kinetic Platform does not guarantee any consistency in behavior of these elements, it is not advised to place code in these places.

Placing the JavaScript in the Bundle

Placing JavaScript within the bundle has these general advantages:

• Functions can be used across multiple forms
• It is easy to see the updates/diffs in a code repository

Placing JavaScript within the bundle has these general disadvantages:

• It is extra overhead to load functions not used on the specific form in question. Additional organization may be able to help limit this.
• Updates to shared bundle functions may require regression testing of multiple forms.
• Anyone working on the JavaScript needs access to view and update the bundle

Using JavaScript for the forms in the bundle is done in two main ways:

• Creating JavaScript as would be in the form in the bundle
• Creating React components in the bundle to be used within the forms

Creating JavaScript as would be in the Form in the Bundle

The idea of this is quite simple. This is a .js function (or several of them) in the bundle and loaded appropriately as the forms require that contain the same types of information and functions as you would use when using the JavaScript in the forms directly. In this case, it is still true that if there is a React library in use in the bundle, it will not be available to the forms and it would be necessary, if that functionality is also required in the forms, to have an additional non-React JavaScript library with that functionality loaded for use.

This is an optimal solution for basic JavaScript functions that are used across all or many forms.

Creating React Components in the Bundle to be Used within the Forms

This solution allows React components to be extended to be available in the bundle. This can reduce duplicate libraries and functions needed in the bundle load, thus reducing overhead. React components aren't the correct implementation for all necessary JavaScript needed, though, so this can have limited applications.