Неизменность времени компиляции в TypeScript

 const sitepoint = {
  name: 'SitePoint',
  isRegistered: true,
  address: {
    line1: 'PO Box 1115',
    town: 'Collingwood',
    region: 'VIC',
    postcode: '3066',
    country: 'Australia',
  },
  contentTags: ['JavaScript', 'HTML', 'CSS', 'React'],
} as const;

Другими словами:

• Открытые примитивы будут сужены до точных литеральных типов (например, as const{
readonly name: 'SitePoint';
readonly isRegistered: true;
readonly address: {
readonly line1: 'PO Box 1115';
readonly town: 'Collingwood';
readonly region: 'VIC';
readonly postcode: '3066';
readonly country: 'Australia';
};
readonly contentTags: readonly ['JavaScript', 'HTML', 'CSS', 'React'];
}

• Объектные литералы будут изменять свои свойства с помощью boolean
• Литералы массива станут кортежами только для truereadonlyreadonly

Попытка добавить или заменить любые значения приведет к тому, что компилятор TypeScript выдаст ошибку:

 string[]

Константные утверждения приводят к типам только для чтения, которые по сути запрещают вызов любых методов экземпляра, которые будут мутировать объект:

 ['foo', 'bar', 'baz']

Естественно, единственным способом использования неизменяемых объектов для отражения различных значений является создание из них новых объектов:

 sitepoint.isCharity = true; // isCharity does not exist on inferred type
sitepoint.address.country = 'United Kingdom'; // Cannot assign to 'country' because it is a read-only property

Неизменные функциональные параметры

Поскольку константные утверждения являются просто синтаксическим сахаром для типизации определенного объявления как набора свойств только для чтения с литеральными значениями, все еще возможно изменять ссылки в теле функций:

 sitepoint.contentTags.push('Pascal'); // Property 'push' does not exist on type 'readonly ["JavaScript", "HTML"...]

Это можно решить, const microsoft = {
...sitepoint,
name: 'Microsoft',
} as const;
interface Person {
name: string;
address: {
country: string;
};
}

const me = {
name: ‘James’,
address: {
country: ‘United Kingdom’,
},
} as const;

const isJames = (person: Person) => {
person.name = ‘Sarah’;
return person.name === ‘James’;
};

console.log(isJames(me)); // false;
console.log(me.name); // ‘Sarah’;
person

 Readonly<Person>

Нет встроенных типов утилит для обработки глубокой неизменности, но, учитывая, что TypeScript 3.7 обеспечивает лучшую поддержку рекурсивных типов , откладывая их разрешение, мы можем теперь выразить бесконечно рекурсивный тип, чтобы обозначать свойства как const isJames = (person: Readonly<Person>) => {
person.name = 'Sarah'; // Cannot assign to 'name' because it is a read-only property.
person.address.country = 'Australia'; // valid
return person.name === 'James';
};

console.log(isJames(me)); // false
console.log(me.address.country); // ‘Australia’
readonly

 type Immutable<T> = {
  readonly [K in keyof T]: Immutable<T[K]>;
};

Если бы мы описали параметр personisJames()Immutable<Person>

 const isJames = (person: Immutable<Person>) => {
  person.name = 'Sarah'; // Cannot assign to 'name' because it is a read-only property.
  person.address.country = 'Australia'; // Cannot assign to 'country' because it is a read-only property.
  return person.name === 'James';
};

Это решение также будет работать для глубоко вложенных массивов:

 const hasCell = (cells: Immutable<string[][]>) => {
  cells[0][0] = 'no'; // Index signature in type 'readonly string[]' only permits reading.
};

Несмотря на то, что Immutable<T>продолжаются дискуссии о внедрении DeepReadonly <T> в TypeScript , который имеет более утонченную семантику.

Пример из реального мира

Redux , чрезвычайно популярная библиотека управления состоянием, требует неизменной обработки состояния, чтобы тривиально определить, нужно ли обновлять хранилище. У нас могут быть интерфейсы состояния приложения и действия, похожие на это:

 interface Action {
  type: string;
  name: string;
  isComplete: boolean;
}

interface Todo {
  name: string;
  isComplete: boolean;
}

interface State {
  todos: Todo[];
}

Учитывая, что наш редуктор должен возвращать совершенно новую ссылку, если состояние было обновлено, мы можем ввести аргумент stateImmutable<State>

 const reducer = (
  state: Immutable<State>,
  action: Immutable<Action>,
): Immutable<State> => {
  switch (action.type) {
    case 'ADD_TODO':
      return {
        ...state,
        todos: [
          ...state.todos,
          {
            name: action.name,
            isComplete: false,
          },
        ],
      };

    default:
      return state;
  }
};

Дополнительные преимущества неизменяемости

В этой статье мы наблюдали, как обработка объектов неизменно приводит к более ясному и детерминированному коду. Тем не менее, есть пара дополнительных преимуществ, которые стоит поднять.

Обнаружение изменений с помощью оператора строгого сравнения

В JavaScript мы можем использовать оператор строгого сравнения ( === Рассмотрим наш редуктор в предыдущем примере:

 const reducer = (
  state: Immutable<State>,
  action: Immutable<TodoAction>,
): Immutable<State> => {
  switch (action.type) {
    case 'ADD_TODO':
      return {
        ...state,
        // deeply merge TODOs
      };

    default:
      return state;
  }
};

Поскольку мы создаем новую ссылку, только если вычислено измененное состояние, мы можем сделать вывод, что строгое равенство ссылок представляет неизмененный объект:

 const action = {
  ...addTodoAction,
  type: 'NOOP',
};

const newState = reducer(state, action);
const hasStateChanged = state !== newState;

Обнаружение изменений по строгому равенству ссылок проще, чем глубокое сравнение двух деревьев объектов, которое обычно включает в себя рекурсию.

Запоминание вычислений по ссылке

В качестве следствия для обработки ссылок и выражений объектов как отношения «один к одному» (т. Е. Одна ссылка представляет точный набор свойств и значений), мы можем запоминать потенциально дорогостоящие вычисления по ссылке. Если бы мы хотели добавить массив, содержащий первые 2000 чисел последовательности Фибоначчи, мы могли бы использовать функцию более высокого порядка и WeakMap для предсказуемого кеширования результата операции по определенной ссылке:

 const memoise = <TArg extends object, TResult>(func: Function) => {
  const results = new WeakMap<TArg, TResult>();

  return (arg: TArg) =>
    results.has(arg) ? results.get(arg) : results.set(arg, func(arg)).get(arg);
};

const sum = (numbers: number[]) => numbers.reduce((total, x) => total + x, 0);

const memoisedSum = memoise<number[], number>(sum);
const numbers = createFibSequence(0, 2000);

console.log(memoisedSum(numbers)); // Cache miss
console.log(memoisedSum(numbers)); // Cache hit

Неизменность — это не серебряная пуля

Как и любая парадигма программирования, неизменность имеет свои недостатки:

• Копирование глубинных объектов с синтаксисом распространения может быть многословным, особенно когда изменяется только одно значение примитива в сложном дереве.
• Создание новых ссылок приведет ко многим эфемерным выделениям памяти, которые, следовательно, должна собирать сборка мусора ;. Это может перебить основной поток, хотя современные сборщики мусора, такие как Orinoco, смягчают это с помощью распараллеливания.
• Использование неизменяемых типов и константных утверждений требует дисциплины и межгруппового консенсуса. В качестве средства автоматизации такой практики обсуждаются конкретные правила оформления , но они представляют собой очень ранние предложения.
• Многие первые и сторонние API, такие как DOM и аналитические библиотеки, смоделированы на основе мутации объектов. Хотя конкретные рефераты могут помочь, повсеместная неизменность в сети невозможна.

Резюме

Мутационный код может иметь непрозрачные намерения и привести к тому, что наше программное обеспечение будет работать неожиданно. Манипулирование современным синтаксисом JavaScript может побудить разработчиков постоянно работать с ссылочными типами — создавать новые объекты из существующих ссылок вместо их прямого изменения — и дополнять их конструкциями TypeScript для достижения неизменности во время компиляции. Это, конечно, не надежный подход, но с некоторой дисциплиной мы можем написать чрезвычайно надежные и предсказуемые приложения, которые в долгосрочной перспективе могут только облегчить нашу работу.