Введение
Последние два месяца я работал над интересным проектом в своей компании, который должен быть очень большим. Итак, сначала, как руководитель группы и основной производитель, я потратил довольно много времени, чтобы найти хорошую отправную точку, я имел в виду такие вещи, как структурирование проекта, какой интерфейсный стек использовать, как этот стек подключается к серверу, как настроить и собрать все эти вещи вместе и т. д., чтобы удовлетворить все требования проекта.
Наконец, я остановился на Meteor для серверной части, React для внешнего интерфейса и Vanilajs ES6 MVC для расширения приложения (это была самая интересная часть). проекта, о нем я расскажу в другом блоге). Сначала все шло хорошо и гладко. Излишне говорить, что React был настолько потрясающим, что я полностью изменил свои мысли при программировании.
Но вскоре, поскольку я впервые создавал такой большой проект с помощью React, все начало запутываться. Я столкнулся с проблемой, которая была у каждого крупного проекта, написанного на React. Поэтому я написал этот пост, чтобы сообщить вам, в чем была проблема и как я пытался ее решить.
Предпосылки
React представлен как простой и очень легкий в освоении для начинающих. Это, безусловно, правда, но, честно говоря, на начальном уровне требуется немало усилий, чтобы придумать это.
К сожалению, этот пост не предназначен для новичков, потому что я пишу об опыте, который я получил в большом проекте, а не только о том, как использовать React для проекта Meteor. Поэтому для понимания того, что я собираюсь написать, от читателей могут потребоваться следующие знания:
- Компонент React-контейнера
- Реагировать на однонаправленный поток данных
- Реагировать Миксины
- Реакция в Метеоре 1.2
- Рамдайс
Проблема, с которой я столкнулся
Я могу охарактеризовать проблему одним словом: обслуживаемый.
Следуя принципу однонаправленного потока данных, я создал компонент-контейнер для каждого маршрута для проблемы. Этот компонент отвечает почти за каждую логику маршрута, для которого он используется. Например. он заботится о методах подписки/вызова с сервера Meteor, является посредником для своих дочерних компонентов, разговаривающих друг с другом. Со всеми этими миссиями вскоре он становится очень большим и толстым парнем.
Файл, в котором я закодировал компонент-контейнер, состоял примерно из 700 строк, когда я только что закончил примерно половину работы. Это было явно неприемлемо. Если бы я проигнорировал эту проблему и продолжал писать код, чтобы выполнить работу быстро, это был бы кошмар для сопровождающего/отладчика.
Зная, что это был основной проект моей компании, а это означало, что мы с коллегами будем работать над ним годами, я перестал кодировать функции и начал просматривать код.
Первая попытка
Я посмотрел на все функции контейнера и понял, что их можно разделить на четыре группы:
- Обязательные функции компонента: getInitialState, getMeteorData, render и т. д.
- Функции обработчика: все обработчики событий для всех дочерних компонентов контейнера.
- Вспомогательные функции: функции, помогающие получить необходимые данные для дочерних компонентов контейнера на основе свойств и состояния контейнера. Там функции — это просто чистые функции, они принимают входные данные и производят выходные данные, не касаясь состояния контейнера и не взаимодействуя с сервером Meteor.
- Логические функции: функции для изменения состояния компонента, вызов методов с сервера. Эти функции вызываются обработчиками событий в ответ на действия пользователя.
Имея в виду эту модель, я разделил функции последних трех групп на три отдельных файла и импортировал их обратно в контейнер с помощью примесей.
Каталог контейнера выглядел так:
root
| ...
|---...
|---poppi:client-container-example-component
|---client
|---components
|---subcomponent1
| ...
|---subcomponent2
| ...
| ContainerExample.jsx
| ContainerExampleContainer.jsx
| ContainerExampleHandlers.js
| ContainerExampleHelpers.js
| ContainerExampleLogicFuncs.js
| package.js
|---...
А также код контейнера
