Using Object Literals as Const for types in arcgis-rest-js over enums

We had updated to use enums in https://github.com/Esri/arcgis-rest-js/issues/654 along with string literals union types.

This resulted in having both enum and string literals union types in the latest release.

We see benefits of using Object Literal as const over enum as it eliminates the need to have both the enum and string literal union types as seen using enums. This new alternative is backwards compatible and keeps the doc more cleaner. Also using this approach we can iterate over values in runtime which is not possible using const enums.

---

It is boiling down to how badly we need the capability to produce an array of all possible string values. If it is needed, as const is looking more plausible.

Ok , another benefit when using the Object Literals is that we don’t have both string union types and enums listed in the types as we have with merged PR.

With Object Literal as const approach IFont.style becomes FontStyle

const FontStyle = {
  Italic: "italic",
  Normal: "normal",
  Oblique: "oblique"
} as const;

export type FontStyle = (typeof FontStyle)[keyof typeof FontStyle];

export interface IFont {
  family?: string; // "<fontFamily>";
  size?: number; // <fontSize>;
  style?: FontStyle;
  weight?: FontWeight;
  decoration?: FontDecoration;
}

Merged PR using const enum

export interface IFont {
  family?: string; // "<fontFamily>";
  size?: number; // <fontSize>;
  style?: "italic" | "normal" | "oblique" | FontStyle;
  weight?: "bold" | "bolder" | "lighter" | "normal" | FontWeight;
  decoration?: "line-through" | "underline" | "none" | FontDecoration;
}

Can we check the impact of doc in both cases?

Object Literal approach preserves the backwards compatibility and provides type for uses who would like to use FontStyle.Normal.

On the question of if we choose enum vs const enum const enum will not add extra lookup table and it is better for smaller bundle sizes but we loose iterating over the values.

On using const enum vs Object Literal, the bundle size will increase with Object as Const approach as we are creating an Object. Const Enum gets resolved at compile time itself.

Overall the merged PR does not have a breaking change , the issue would be that we will have both string union types and enum, this might confuse the user. Other than that it is a good solution.

Since JS does not have native enum support, there is a stage 0 proposall which may deviate from TS enums. So there is group of users who suggest to avoid Enums and use alternatives like Object Literal as const approaches. The Pro Enum group advocate string based enums are good.

I believe it boils down to on the API if we want to use enums or alternatives to enums to provide Types instead of string union types.

If we want to decide purely on bundle size, string based const enums are good though we miss capability to iterate over possible values.

If we want the iteration over possible values Object based approach as const is better alternative than producing lookup table with using enum.

Comparisons of various approaches

cc: @dasa

_Originally posted by @subgan82 in https://github.com/Esri/arcgis-rest-js/pull/656#issuecomment-592543437_

---

We do use const enum, but we can’t use as const yet since we’re still on TS 3.3, but that does seem to be the preferred way going forward unless you need to performance of const enum and don’t need the runtime inspection.

_Originally posted by @dasa in https://github.com/Esri/arcgis-rest-js/pull/656#issuecomment-592577726_

[subgan82]

For these reasons I would really like to just merge #681 and close this issue.

👍

[subgan82]

is adding --isolatedModules option to TSC useful to catch such errors in future. https://www.typescriptlang.org/docs/handbook/compiler-options.html

--isolatedModules | boolean | false | Perform additional checks to ensure that separate compilation (such as with transpileModule or @babel/plugin-transform-typescript) would be safe.
-- | -- | -- | --