Совместное использование инструментов, которые мы приняли на ProductReview.com.au, чтобы повысить уверенность разработчиков при работе с путями маршрутизации

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

С самого начала наша команда определяла каждый отдельный путь в картах маршрутизации Symfony в файлах YAML и выгружала их в файлы JS, чтобы мы могли использовать одни и те же имена маршрутов как во внутренней, так и во внешней части. Это действительно помогло, поскольку выдает ошибку, когда путь не определен, но мы все же могли сделать многое лучше. Примерно так это выглядело:

Неплохо, но не отлично. Используя аннотации типов, мы могли бы значительно улучшить опыт разработчиков:

  • Текстовый редактор показывает все доступные пути, и вы не можете использовать тот, который не определен
  • Типизированные параметры не позволяют передавать недопустимые значения
  • Типизированные параметры придают вам уверенность при использовании их внутри компонента страницы, потому что вы знаете, какие из них определены, а также их типы.

Вы можете задаться вопросом… как, черт возьми, будут создаваться аннотации? В конце концов, мы не хотим делать это вручную! Здесь пригодится знакомство с абстрактными синтаксическими деревьями. Я разработал скрипт, который получает список путей и выводит файл JavaScript с аннотациями типов, которые совместимы с Flow и TypeScript, и вы можете запустить его, например, в ловушке перед фиксацией.

Во-первых, так определяется наша функция getPath:

А затем несколько автоматически сгенерированных определений (пример):

И можно было бы использовать это так:

getPath (СТАТЬЯ, {…});

В ваших маршрутах:

‹Путь маршрута = {ARTICLE_PATH_MASK} компонент = {ArticlePage} /›

И расширьте определение свойств компонента страницы с помощью ArticleParams:

type Props = {
params: ArticleParams,
//…
};

В общем, мы стараемся, чтобы наши определения путей были как можно более простыми. Чем они сложнее, тем сложнее автоматически создавать аннотации. Иногда это невозможно сделать, и необходимы проверки во время выполнения (например, тест RegEx выше). Некоторые новые функции, которые могут быть реализованы в будущем: 1. проверки на запрет значений, содержащих косые черты, и 2. параметры, охватывающие одну или несколько косых черт, например /*path >> /dirA/dirB/fileName.jpg.

Опыт

Преимущества были довольно очевидными:

Проверки происходят как в наших текстовых редакторах, так и на нашем сервере непрерывной интеграции.

Устранение мертвого кода

Еще одним преимуществом представленного подхода является то, что мы можем уменьшить размеры пакетов, поскольку Webpack позаботится об удалении неиспользуемых путей. Это также можно интерпретировать как функцию безопасности, потому что вы не хотите, чтобы эти конфиденциальные пути были включены в ваше общедоступное приложение. Но имейте в виду, что выполнение import * as paths from 'myfile'; предотвратит это.

Если вас интересует преобразование AST / кода, обратите внимание на react-codemod и awesome-babel. И вот файлы поддержки для этой истории Medium.

Кстати, мы набираем! Если вы готовы решать большие задачи с помощью крутых технологий в солнечном и красивом Сиднее, напишите нам свое резюме по адресу [email protected].