Почему примеры архитектуры Flux используют константы для типов действий вместо строк?

Всюду по примерам и объяснениям архитектуры Flux - сопоставление Facebook с именами типа React - действия упоминаются как константы перечисления, а не строки. (См. Примеры на http://facebook.github.io/flux/) Я просто ищу артикуляцию того, почему это предпочтительный метод.

Я не вижу преимущества с точки зрения авторства и удобства, потому что, если вы набираете constants.actionTypes.UPDATE_DATA (enum constant) или 'UPDATE_DATA' (string), вам нужно знать и печатать точное имя. Фактически, иногда использование не-строк добавляет сложности - например. вы не можете так легко сделать объект с типом действия как ключи и обработчики действий как значения.

Являются ли преимущества в организации, минимизации или чем-то еще? Мне любопытно.

Ответ 1

Вы затронули его в конце своего вопроса, но есть несколько преимуществ. Минимизация очевидна; другой - тот факт, что инструменты статического анализа могут легче находить способы использования и ломать ошибки.

В зависимости от вашей реализации потока они также могут помочь вам уловить опечатки. Например, в Fluxxor, если вы попытаетесь связать обработчик хранилища с типом действия undefined, вы получите исключение; это означает, что передача c.UPDATE_DTA будет выбрасываться, но передача 'UPDATE_DTA' не будет.

Наконец, они могут помочь в качестве документации. Если все типы действий, которые генерируется вашим приложением, определяются централизованно как константы, становится легче понять, на какие операции реагирует система в целом.

Там есть функция ES6, доступная с Babel или Traceur (но не с преобразование JSX в это время), которое помогает создавать объектные литералы; синтаксис:

var handlers = {
  [const.UPDATE_DATA]: this.handleUpdateData,
  [const.OTHER_THING]: this.handleOtherThing
};