The Kinetic Platform is a flexible tool used to create and maintain Business Solutions for a multitude of industries and applications. As such, there is often no one correct answer to architecture and development decisions made in the process of creating or maintaining said solutions. The answers to these decisions depend on many factors including current and future scale and growth potential, both of customer base and development staff, technical specifications for the solution, and more. To address the need to answer these questions that do not have a simple answer, we have created this Examining Best Practices series of articles.

This article will address the placement of javascript for use within forms of a solution. This refers to javascript that is used in forms rather than in the bundle/theme.

There are a number of potential solutions for javascript for forms:

• Placing javascript within the form itself
  • Placing the javascript in a form load event
  • Placing the javascript in the event where it is used
• Placing the javascript in the bundle
  • Creating javascript as would be in the form in the bundle
  • Creating REACT components in the bundle to be used within the forms

Each option has its pros and cons, and a final solution does not need to consist entirely of one of these options, but can consist of some or all of them in combination, where appropriate.

Javascript within the Form

There a number of ways to put javascript functions within the form. There are two that are not advised because of unpredictability:

• Placing the javascript in the form 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 javascript within the form has these general advantages:

• Anyone working on the form can view and update the javascript
• The functions can be specific to the form they are on
• When the functions are edited, there is no need to regression test other forms
• If there is a REACT library loaded in the bundle, it is not available to the forms. It would be necessary, if that functionality is also required in the forms, to have an additional non-REACT JS library with that functionality loaded for use.

Placing javascript within the forms has these general disadvantages:

• There can be duplication of code (and maintenance of code) if the same function is needed across more than one form.
• Out of the box exports for Kinetic Forms compresses the events into a single line, making updates hard to read/diff in a code repository.

There are two primary ways of handing this javascript within the 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.

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 JS 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.