Code

Code is where you create and manage reusable JavaScript and CSS files for the frontend of an ioLoop Project.

Use Code when Pages, Forms, Page Flow, Widgets, or visual layouts need browser-side functionality or styling that is easier to maintain in a named Project asset rather than repeating it in several places.

Creating a Code file does not automatically load it on a Page or Form. After creating and saving the file, include it at the Project level or on the specific Pages and Forms that need it.

Code assets run in the browser when included. Use Cloud Flow for trusted processing, protected credentials, and business rules that must be enforced on the server.

What Code Is For

Frontend Code provides a reusable home for application styling and browser-side logic.

Common uses include:

• Shared CSS for branding, typography refinements, Cards, menus, and other interface components.
• JavaScript helpers called from Page Flow.
• Value formatting, calculations, and data transformations.
• Reusable browser-side validation helpers.
• Specialized behavior for Page Elements and Widgets.
• Page-specific code that is easier to maintain outside a large Page Flow.
• Browser-side integrations that are appropriate to expose to the user's browser.

For example, several Pages might use the same CSS class for dashboard summary Cards. Instead of defining the style separately on every Page, define it once in a CSS Code file and include that file wherever it is needed.

Similarly, several Page Flows might use the same currency-formatting helper. Keeping the helper in one JavaScript Code file makes it easier to update consistently.

Do not use frontend Code as a substitute for Backend operations that require secrets, privileged access, or independently enforced authorization.

Code File Types

ioLoop supports two frontend Code file types:

Type	Purpose
Page/Form JavaScript	Defines browser-side JavaScript used by included Pages and Forms.
Page/Form CSS	Defines CSS styles used by included Pages and Forms.

Choose the file type when creating the asset. The selected type determines how the editor handles and validates its content.

The Code file name does not need a .js or .css extension.

Naming Code Files

Use short, meaningful names that describe the asset's responsibility, such as:

• ProjectTheme
• DashboardStyles
• CheckoutHelpers
• FormValidationHelpers
• DataTableFormatting

Code file names should use letters and numbers. Avoid spaces, punctuation, temporary names, and names copied directly from local files when they are not meaningful within the Project.

Name files according to what they do rather than where they happen to be used today. A general-purpose formatting helper can remain useful even if the Page that first needed it changes.

Code Assets, Page Flow, and Cloud Flow

These capabilities work together but have different responsibilities.

Capability	Use It For
Page Flow blocks	Coordinating browser-side events, interactions, Forms, Widgets, navigation, and data operations.
Custom Code block	Executing focused JavaScript statements within a Page Flow.
Code Expression block	Producing a JavaScript value for another Page Flow block.
Frontend Code assets	Maintaining reusable JavaScript and CSS independently of individual Page Flow blocks.
Cloud Flow	Running trusted server-side processing and operations that require protected capabilities.

A Page Flow can call JavaScript helpers provided by a Code asset included on the Page. The helper must be available in the browser at the time the flow uses it.

The usual division is:

1. Page Elements present the interface.
2. Page Flow responds to actions and coordinates the experience.
3. Included JavaScript Code files provide reusable browser-side helpers.
4. Included CSS Code files provide reusable styling.
5. Cloud Flow performs trusted Backend work when required.

Keep the primary user workflow understandable in Page Flow rather than hiding an entire interaction inside one large helper file.

For more information, see Page Flow and Custom Code.

Creating a Code File

To create a Code asset:

1. Open the Project in the Project Editor.
2. Open Frontend.
3. Select Code.
4. Choose New.
5. Enter a meaningful file name.
6. Select Page/Form JavaScript or Page/Form CSS.
7. Save the new asset.
8. Open the asset and add its JavaScript or CSS.
9. Save the Code content.
10. Include the Code asset at the Project or Page level where it is needed.
11. Preview the affected Page or Form.

New Code files start empty. The file type is chosen when the asset is created and is not changed later by renaming the file.

The Code area can show files as tiles or in a table-style listing. The table-style listing shows the file name, type, and Access (Security) information. Select a file to open the file's action menu.

Editing Code

Select a Code file and choose Edit to open its editor.

The editor provides capabilities such as:

• Editing JavaScript or CSS according to the file type.
• Saving changes.
• Validating the content when it is saved.
• Project-aware sidebars for finding and copying relevant names and references.

JavaScript Validation

When saving a Page/Form JavaScript file, ioLoop checks its JavaScript syntax and reports invalid code so it can be corrected.

Valid syntax does not guarantee that the code will behave correctly when the Page runs. A script can pass validation but still encounter a missing function, unexpected value, unavailable element, or failed request.

CSS Validation

When saving a Page/Form CSS file, ioLoop validates the CSS before storing the saved content.

Valid CSS does not guarantee that a rule matches the intended element or takes precedence over another style. Check the result in Preview, especially when custom CSS interacts with Element Settings or responsive layouts.

Save Code changes before Previewing Pages and Forms that include those assets.

Editor Sidebars

The Code editor provides Project-aware reference sidebars to help you use the right Project identifiers and supported APIs.

Depending on the file type and editing context, these can include:

• Pages and Forms.
• Data Designs and related elements.
• Database tables, fields, and queries.
• Connections and supported commands.
• Cloud Flow Web Hooks.
• Client API documentation.

Supported sidebar actions can help you copy names, templates, or call-related information without retyping them manually.

For example, when JavaScript needs to reference a Project table or a supported Client API operation, using the available reference information can reduce errors caused by misspelled names or incorrect assumptions about an API.

The sidebars assist authoring; they do not execute the file or automatically include it. The Code asset must still be saved, included at the correct scope, and used in the appropriate browser-side execution context.

For exact API functions and calling conventions, see the Client API reference.

Including Code Files

Creating a Code file stores it in the Project. Inclusion determines where the file is loaded.

There are two main inclusion scopes:

Scope	Configuration	Best For
Project-level Code	Project Settings	Shared styling or JavaScript intended for broad use across the Project.
Page-level Code	Page Settings → Code	Assets required by a particular Page or Form.

Project-Level Inclusion

Use Project-level Code for assets that should be available broadly, such as:

• Shared brand or theme CSS.
• Common formatting helpers.
• JavaScript utilities called by several Pages or Forms.
• Shared styles for recurring interface patterns.

Project-level inclusion reduces repeated configuration, but it can also cause a change to affect multiple Pages. Review the impact before modifying a widely included asset.

Page-Level Inclusion

Use Page-level Code for assets that belong to a specific Page or Form, such as:

• Dashboard-only CSS.
• Helpers for one specialized Form.
• A script used by a particular Widget or visual interaction.
• Styling for one campaign or landing Page.

To include a file on a particular Page or Form:

1. Open that Page or Form in the Page Editor.
2. Open Page Settings.
3. Select Code.
4. Select the required JavaScript and CSS assets.
5. Arrange their load order when dependencies require it.
6. Save Page Settings.
7. Preview the Page or Form and verify the behavior.

For the corresponding configuration options, see Page Settings — Code.

When choosing included files, use Add File to select an existing Code asset. Use the available move controls to reorder included files, and remove files that are no longer needed by that Page or Form.

The included-file list stores the selected Code file names and their types. It does not create new Code files; create the asset in Frontend → Code first, then include it where needed.

Choosing the Right Scope

Use the narrowest scope that comfortably supports the intended reuse. A helper used on ten Pages is a good candidate for Project-level inclusion; a script needed on only one Page is usually better included there.

Do not assume that a file is available merely because it appears in the Code list. Confirm its inclusion on the Page where it is needed.

Load Order and Dependencies

Included Code files can be arranged in a loading order.

Load order matters when one JavaScript file depends on code defined by another, or when CSS files contain rules that may affect the same elements.

JavaScript Load Order

For example:

Order	Asset	Responsibility
1	SharedHelpers	Defines common utilities.
2	CheckoutHelpers	Uses those shared utilities.
3	CheckoutPage	Provides specialized browser-side behavior for checkout.

When a helper depends on another included file, make sure the dependency becomes available before the helper is used.

File inclusion order and actual execution timing are related but not identical concerns. Code that depends on Page Elements must also run when those elements are available, and Page Flow must not invoke a helper before the helper has been loaded.

CSS Load Order

When multiple CSS files apply competing declarations, their order can affect the final appearance. Rules with equal precedence and specificity may be resolved in favor of a later definition.

CSS specificity, inheritance, and existing element styles can also affect the result. Moving a file later in the list does not guarantee that every rule in it will override an earlier rule.

Preview the affected Pages whenever a shared CSS file or its loading order changes.

JavaScript Code Files

Page/Form JavaScript files contain browser-side code used by the Pages and Forms that include them.

Typical uses include:

• Formatting values before displaying them.
• Preparing objects or transforming data for Page Flow.
• Reusing calculation or validation helpers.
• Supporting specialized interface behavior.
• Calling supported browser-side ioLoop APIs.
• Coordinating behavior that is clearer in JavaScript than in visual blocks alone.

Example: Reusable Currency Formatting Helper

Suppose several Pages display currency values in the same format. A JavaScript Code asset can define a shared browser-side helper:

window.projectHelpers = window.projectHelpers || {};

window.projectHelpers.formatCurrency = function (value) {
  const amount = Number(value);

  if (!Number.isFinite(amount)) {
    return '—';
  }

  return new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: 'USD'
  }).format(amount);
};

The example uses standard browser JavaScript and makes the helper available through window.projectHelpers. It is not an ioLoop-specific API.

A Page Flow Custom Code or Code Expression block on a Page that includes the asset can use that helper when it is available, for example:

window.projectHelpers.formatCurrency(89.5)

This expression produces a formatted currency value that the surrounding Page Flow can use.

To configure this pattern:

1. Create and save a JavaScript Code asset containing the helper.
2. Include the asset in Project Settings or the appropriate Page Settings.
3. Configure Page Flow to use the helper where it is needed.
4. Save Page Flow.
5. Preview the Page and test representative values, including invalid or missing values.

If the helper is not found at runtime, first confirm the file's inclusion and execution timing. Keep shared names deliberate to avoid conflicts with other included scripts.

Browser-Side Limitations

JavaScript in frontend Code is delivered to the browser and operates within the permissions of the browser-side application.

It must not contain:

• Private API keys or credentials.
• Protected tokens or internal secrets.
• Authorization logic that must be independently enforced.
• Sensitive business rules that depend on trusting the browser.

Use Cloud Flow and appropriate Database access rules for operations requiring trusted enforcement.

CSS Code Files

Page/Form CSS assets provide reusable styles for Pages and Forms.

Use them for:

• Shared visual treatments.
• Custom classes applied through Element Settings.
• Styles used by multiple Cards, panels, menus, or data-driven components.
• Layout refinements beyond the standard Design controls.
• Page- or section-specific styles.

For basic element appearance, prefer the standard Design settings. Use CSS when the styling needs to be reused or cannot be expressed clearly through those controls.

Example: Reusable Summary Card Style

Suppose a dashboard contains several Cards with the same presentation. Create a CSS Code asset containing:

.summary-card {
  border: 1px solid #d7dee7;
  border-radius: 10px;
  padding: 16px;
  background-color: #ffffff;
}

@media (max-width: 640px) {
  .summary-card {
    padding: 12px;
  }
}

Then:

1. Save the CSS Code asset.
2. Include it at the appropriate Project or Page scope.
3. Select each applicable Card in the Page Editor.
4. Apply summary-card through Custom CSS Classes in Element Settings, where supported.
5. Save and Preview at desktop, tablet, and mobile widths.

The CSS class connects the Page Element to the reusable style. An Element Name is not the same thing as a CSS class.

For more information, see Element Settings.

CSS Assets vs. Page Settings Custom Styles

Page Settings also provide Custom Style definitions for localized CSS.

Need	Recommended Approach
A small, one-Page CSS adjustment	Page Settings → Advanced → Custom Style definitions
Repeated styling across several elements	CSS class in an included CSS asset
Shared styling across multiple Pages	Project-level CSS asset
Specialized CSS for one Page	Page-level CSS asset

Avoid maintaining multiple conflicting definitions for the same visual treatment unless the cascade behavior is intentional.

Access and Security

Code files can expose an Access (Security) action in the Code listing.

Use the available access configuration according to the Project's security model. However, access configuration and Code inclusion serve different purposes:

• Access (Security) controls the asset's configured access behavior.
• Project- or Page-level inclusion determines where the asset is loaded.
• Browser execution means that code delivered to an application visitor should be regarded as inspectable by that visitor.

Do not use frontend Code asset access settings as a substitute for protecting confidential logic or secrets.

For sensitive operations, apply the appropriate Database permissions and trusted Backend authorization. Hiding a Button, restricting a Page, or omitting an action from a menu is not a sufficient authorization check for the operations behind it.

Managing Code Files

Select an existing Code file to access its management actions.

Action	Purpose
Edit	Opens the asset in the JavaScript or CSS editor.
Access (Security)	Opens the asset's access configuration.
Rename	Changes the asset's name.
Clone	Creates a copy for reuse or variation.
Delete	Removes the asset from the Project.

These actions are available from the selected file's action menu in the Code list.

Access Security

Use Access (Security) to configure which Project Users or User Groups can access the Code file according to the Project's security model.

For the identities, built-in groups, custom groups, and role levels available to resource access settings, see User Groups. To create Project User accounts and assign their membership, see Users.

Access configuration is separate from inclusion. A file still needs to be included at Project or Page level before it is loaded by a Page or Form.

Renaming or Deleting an Asset

Before renaming or deleting, check whether the file is included in:

• Project Settings.
• Page Settings on one or more Pages or Forms.
• A set of assets that depends on the file's functions or styles.

A renamed or deleted asset may leave dependencies or inclusion references that need attention. Do not assume the editor automatically repairs every reference.

Renaming changes the Code file name. It does not change whether the file is JavaScript or CSS.

A safer replacement workflow is:

1. Create or clone the replacement asset.
2. Update its content and save it.
3. Include it where required, with the correct load order.
4. Preview every affected Page or Form.
5. Remove the previous asset from inclusion settings when it is no longer required.
6. Delete the old asset only after the replacement has been verified.

Cloning an Asset

Cloning is useful when a Page needs a variation of an existing helper or stylesheet without changing the original.

When cloning, choose a new file name. The clone starts from the original file's type and content.

After cloning, review its contents, include it where required, and test the affected Page. Cloning alone does not establish the new file's inclusion scope.

Previewing and Publishing Code

After saving a Code asset or changing its inclusion settings, use Preview to test the saved development version.

Verify that:

• The Page or Form includes the intended asset.
• JavaScript helpers are defined before the Page Flow uses them.
• Startup and event-driven behavior work correctly.
• CSS matches only the intended elements.
• Load order is correct for dependent assets.
• Widgets and Forms still behave correctly.
• Shared Project-level files do not unexpectedly affect unrelated Pages.
• Layout and styling work at desktop, tablet, and mobile sizes.
• Appropriate Project User access scenarios are tested.

Save, Preview, Publish Project, and Launch Project are separate actions. Saving a Code file makes it part of the development state; Preview tests that state; publishing releases it; and Launch Project opens the published application for verification.

When Code or Page Flow performs built-in Database operations during Preview, those operations automatically use the development database. External services and Integrations have their own configured environments and may still cause real external effects. See Previewing.

Troubleshooting

Symptom	What to Check
A Code file has no effect	Confirm it is saved and included at the correct Project or Page scope.
A JavaScript helper is undefined	Check inclusion, load order, execution timing, and how the helper is exposed.
A Page Flow works on one Page but not another	Confirm both Pages include the required asset or receive it through Project-level configuration.
CSS does not apply	Check the class name, file inclusion, selectors, and competing rules.
CSS affects unrelated content	Review broad selectors and Project-level inclusion.
Code saves but fails in Preview	Inspect runtime errors, missing data or elements, and failed browser-side operations.
A Code asset stops working after a rename	Review inclusion references and dependent code.
Preview works but published behavior differs	Confirm the Project was published and the published configuration includes the intended asset.

When troubleshooting, change one factor at a time: first confirm the asset is included, then confirm it loads, then verify the behavior it is supposed to provide.

Choosing the Right Tool

Requirement	Start With
Configure page interaction or events	Page Flow
Add a short JavaScript operation inside a Page Flow	Custom Code
Maintain reusable browser-side JavaScript	Page/Form JavaScript in Code
Apply shared styles across Pages	Page/Form CSS in Code
Apply a small page-specific style	Page Settings
Manage frontend images and public files	Media
Perform trusted server-side work	Cloud Flow

Good Practices

• Choose the right responsibility. Keep workflow coordination in Page Flow, reusable helpers and styling in Code, and trusted operations in Cloud Flow.
• Include assets deliberately. A saved file is not automatically loaded on every Page.
• Use clear names. Prefer stable names that describe the asset's purpose.
• Keep dependencies ordered. Load JavaScript dependencies before code that uses them.
• Use Project-level inclusion thoughtfully. Shared changes can affect many Pages and Forms.
• Prefer reusable CSS classes. Avoid copying the same custom rules into many elements.
• Keep browser-side code public-safe. Never place private credentials or trusted authorization decisions in frontend JavaScript.
• Test save-time and runtime behavior separately. Syntax validation does not establish correct execution.
• Preview before publishing. Then verify the published experience with Launch Project.

Common Mistakes

Avoid these patterns:

• Creating a Code file but never including it.
• Assuming a file is available in every Page Flow simply because it exists in the Project.
• Ignoring load order when helpers depend on other JavaScript files.
• Declaring a helper in a scope that the calling Page Flow cannot access.
• Treating valid JavaScript or CSS syntax as proof that the intended runtime behavior works.
• Applying very broad CSS selectors that unintentionally restyle other Pages.
• Putting a one-Page customization at Project level without considering other Pages.
• Storing secrets or server-only business rules in frontend Code.
• Renaming or deleting an asset before reviewing its inclusion and dependencies.
• Assuming Code access settings protect code that is already delivered to a visitor's browser.
• Forgetting to test the published Project after releasing Code changes.

Frontend Code is most effective when reusable logic and styling are kept separate from the visual interface and its Page Flow, while inclusion, dependencies, and trusted Backend boundaries remain explicit.

Related Topics

• Frontend
• Pages & Forms
• Page Settings
• Element Settings
• Page Flow
• Custom Code
• Previewing
• Media
• Client API
• Cloud Flow
• Publish Project
• Users
• User Groups