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

Спомням си старите дни, когато използвах да соча към други страници или крайни точки на API, използвайки пътища на низове, но този подход има няколко недостатъка, които много лесно могат да доведат до лошо изживяване на разработчиците, тъй като не е безопасно, защото може да подадете невалидни параметри, трудно е за замяна, когато настъпи промяна и е трудно да запомните всички пътища, дефинирани от вашите сървъри.

От самото начало нашият екип дефинира всеки един път в рамките на картите за маршрутизиране на Symfony в YAML файлове и ги изхвърля в JS такива, така че да можем да използваме едни и същи имена на маршрути както в задния, така и в предния край. Това наистина помогна, тъй като извежда грешка, когато пътят не е дефиниран, но все още имаше много неща, които можехме да направим по-добре. Приблизително така изглеждаше:

Не е лошо, но не е и страхотно. Чрез използване на анотации за типове бихме могли значително да подобрим изживяването на разработчиците:

  • Текстовият редактор показва всички налични пътища и не можете да използвате такъв, който не е дефиниран
  • Въведените параметри ви предпазват от предаване на невалидни стойности
  • Въведените параметри ви носят увереност, когато ги използвате в компонент на страница, защото знаете кои от тях са дефинирани, както и техните типове

Може би се чудите обаче... как, за бога, ще бъдат генерирани анотациите? В крайна сметка ние не искаме да правим това ръчно! Това е моментът, когато запознаването с „абстрактните синтактични дървета“ е полезно. Разработих скрипт, който получава списък с пътища и извежда JavaScript файл с анотации за тип, които са Flow- и TypeScript-съвместими, и можете да го стартирате например в кука за предварително ангажиране.

Първо, така се дефинира нашата функция getPath:

И след това куп дефиниции, които се генерират автоматично (пример):

И човек би го използвал така:

getPath(АРТИКУЛ, { … });

Във вашите маршрути:

‹Route path={ARTICLE_PATH_MASK} component={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. И ето са поддържащите файлове за тази средна история.

Между другото, ние наемаме! Ако сте готови да решавате големи предизвикателства със страхотни технологии в слънчевия и красив Сидни, пишете ни на [email protected] с вашето резюме.