Трите прасета: как да структурирате приложението си React-Redux

Определянето на всякакъв вид „добри практики“ в технологиите винаги е труден бизнес. Добрите практики са субективни, силно зависят от начина ви на работа и често от личните ви предпочитания. Най-доброто, което можем да направим, е да разчитаме на опита на другите и да се поучим от техните грешки.

Да започнеш с Redux може да бъде доста обезсърчително и да измислиш най-добрия начин да групираш битовете и частите на приложението си в разумна структура на папки, може да е сложно. След като бях участвал в три проекта на React Redux на зелено поле през последната година, трябва да обмисля някои подходи, свързани с различните подходи, които предприехме, за да завършим с най-добрия ни кадър досега.

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

Къщата със сламената: Стандартно оформление

В първия проект целият екип беше нов в Redux. И за да бъда честен, Redux беше нов за света (вози вълната!). Играхме го безопасно и отидохме със стандартно оформление, както е описано в невероятните (и БЕЗПЛАТНИ) видеоклипове на Egghead на Дан Абрамов.

/ SRC
  / компоненти
  / контейнери
  / дейности
  / редуктори
  / саги

Това е очевидното оформление и това, което повечето хора отиват: групират един и същ „тип“ неща заедно. Това е блестяща отправна точка, но когато се работи с големи приложения, става доста ясно, че това оформление не мащабира. Да предположим, че имаме приложение за ToDo списък и помислете, че потребителят добавя нов ToDo елемент. Вероятно бихте имали компонент ToDoItemList, контейнер ToDoItemList, действие ADD_TODO, редуктор на todoItems и ако трябва да правите API обаждания, за да запазите своите ToDos, сага на ToDoList. Това е ужасно много файлове, разпръснати около кодовата база, които в крайна сметка работят върху една и съща задача. Освен това някои неща просто принадлежат заедно: никога не бихте използвали контейнера ToDoItemList с различен компонент, така че наистина трябва да живеят в различни части на кодовата база?

Дървената къща: Група по функции

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

/ SRC
  / компоненти
    / PureComponent1
      index.js
      index.spec.js
      style.css
    / PureComponent2
      index.js
      index.spec.js
      style.css
    / PureComponent3
  /Характеристика
    / feature1
      component.js
      container.js
      actions.js
      reducer.js
      saga.js
    / feature2
    / feature3

Това оформление минимизира прескачането в кодовата база при разработване на функции. Започна наистина добре, но след известно време стана ясно, че линиите между функциите са замъглени. Как да очертаете линията между потребител, акаунт и профил? Всички еднакви ли са? Освен това е лесно да завършите само с една или две обемисти „характеристики“, които обхващат цялото приложение.

Каменната къща: Групиране по функция

Положението на каменната къща се появи основно, като остави кодовата база да расте естествено. От самото начало направихме минимално възможното количество работа САМО за функцията, която работим, рестартирахме A LOT, положихме голямо внимание да не оптимизираме твърде скоро и добавихме групировки и абстракции само при нужда. Вече сме 4 месеца в проекта и ето какво разработихме:

/ SRC
  / компоненти
    / Component1
      index.js <- може да е чист компонент или компонент, увит в контейнер, потребителят изобщо не се интересува
      index.spec.js
    / Component2
    / Component3
  / редуктори
    index.js
    / Reducer1
      index.js <- действията са в същия файл като редукторите
      index.spec.js
      someSideEffect.js <- тук използваме redux-loop
    / Reducer2
    / Reducer3

Докато този начин на оформление на приложението може да изглежда малко трудно първоначално, досега той е разработен много добре за нас. Групирането на различни „типове“ файлове заедно не е нова идея. В крайна сметка в повечето React приложения тестовите файлове и css файловете живеят в директорията на компонента, към който принадлежат.

В никакъв случай не съм завършил развитието си с каменната къща и бих искал да чуя за други идеи. Ако имате различен тип къща (оформление на папки) от който и да е от изброените тук, уведомете ме :)

Честит редуксинг!