Constant Definitions

As you customize kintone more extensively, you will find yourself using the same values in multiple places. In such cases, defining constants and referencing them from multiple locations can enhance the maintainability of your code. This is a common practice, but how do you implement constant definitions?

I have been customizing kintone for a long time, and there are indeed many ways to implement constant definitions, so I still often wonder what the best method is.

On this site, we have introduced constant definitions in kintone several times, but we have only covered the basics, which might be insufficient for actual projects.

So this time, I would like to introduce a method that has worked well for me.

The Simplest Method

First, let’s introduce the simplest method.

It is straightforward and easy to understand, and overall, it might be the best method.

export const API_SAMPLE_URL = 'https://api.example.com';
export const API_SAMPLE_TEST = 'https://sample.example.com';
export const COMMON_VALUE = 'commonValue';

If you are using an editor like VSCode, it will reference this file when you type API, so you won’t make mistakes with constant names.

Additionally, when you build, unnecessary data won’t be included, which is another advantage.

Of course, you can also group all constants into a single Object.

export const CONSTS = {
  API_SAMPLE_URL: 'https://api.example.com',
  API_SAMPLE_TEST: 'https://sample.example.com',
  COMMON_VALUE: 'commonValue',
} as const;

Environment Variables for Server-Side Code

If you are writing server-side code and deploying the built code to kintone, using environment variables is common.

Specifically, you can use dotenv](https://www.npmjs.com/package/dotenv) to define constants in a [.env file and reference them with process.env.

If you want to use different values for production and development environments, you can prepare separate .env files and determine which to use with process.env.NODE_ENV.

API_SAMPLE_URL=https://api.example.com
API_SAMPLE_TEST=https://sample.example.com
COMMON_VALUE=commonValue

import dotenv from 'dotenv';
dotenv.config();

process.env.API_SAMPLE_URL; // https://api.example.com
process.env.API_SAMPLE_TEST; // https://sample.example.com
process.env.COMMON_VALUE;  // commonValue

If your development environment is fixed and you can always reference the process variable, this method is the simplest.

An Approach Using an Environment Variable App

When searching for solutions to constant definitions on the web, I found an interesting approach.

This method involves defining environment variables as an app and referencing them when needed.

kintone: Defining Constants in JavaScript as an App

Indeed, with this method, you can keep your JavaScript files slim and handle environment-specific changes.

Additionally, since you can change constants from the app, non-engineers can easily modify them. Moreover, you don’t need to rebuild every time you change a constant.

The potential issue might be the impact on execution speed. You can solve this with effective caching, but it might be a bit advanced.

If you only need to change constants periodically, this method might be the most suitable.

Automatically Switching Constants Based on the Environment

Finally, let me introduce the method I use the most.

const prod = {
  'api.sample.url': 'https://api.example.com',
  'api.sample.test': 'https://sample.example.com',
  'common.value.prod': 'onlyProd',
} as const satisfies Record<string, string>;

const dev: Partial<Record<keyof typeof prod, string>> = {
  'api.sample.url': 'http://localhost:3000',
  'api.sample.test': 'http://localhost:3000',
};

const c = { prod, dev };

export const useConsts = (env: keyof typeof c) => {
  return (key: keyof typeof prod): string => {
    return c[env][key] ?? c.prod[key];
  };
};

export const consts = useConsts(process.env.NODE_ENV === 'production' ? 'prod' : 'dev');

The reason for currying is to separate the environment determination, so you can switch constants for different environments by changing only the last line.

The sample code assumes Node.js, so it determines the environment with process.env.NODE_ENV === 'production' ? 'prod' : 'dev' and returns a function called consts.

Even in environments where process is not available, you can use this method by modifying the determination logic, making it a versatile code for both backend and frontend.

The challenge might be that all constants for both production and development environments are included in the built code.

In practice, you would use it as follows:

import { consts } from './consts';

console.log(consts('api.sample.url')); // https://api.example.com

With type inference, you won’t make mistakes with constant keys. Additionally, if you change a constant, a type error will occur, ensuring high safety.