«Эта статья участвовала в мероприятии Haowen Convocation Order, щелкните, чтобы просмотреть:Двойные заявки на внутреннюю и внешнюю стороны, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!"
Эта статья предназначена не только для читателей React.За исключением содержимого стека технологий React, которое тесно связано с другими вещами, это полностью проекты, которые можно применить к любому стеку технологий.
Как правило, внутри компании разрабатывается новый проект, устанавливаются и затем запускаются строительные леса. В результате некоторым разработчикам будет не хватать некоторых знаний, например, почему мы выбираем этот стек технологий для разработки; как сделать инженерную настройку в проекте, начав работу, вы будете растеряны; что такое скаффолдинг (немалый часть Читатели и друзья думают, что строительные леса — очень мощная вещь), как построить строительные леса корпоративного уровня, подходящие для развития бизнеса.
Проект React будет включать в себя много общего, но также и много вариантов. Индивидуальная разработка может быть интегрирована по желанию в соответствии с собственными предпочтениями, но в сценарии многопользовательской разработки нескольких проектов набор спецификаций ограничивает всех. Основываясь на следующем наброске, эта статья расскажет читателям о том, как мы разработали проект React корпоративного уровня и как мы, наконец, интегрировали этот набор вещей в каркас.
Предположим, вы сейчас работаете в компании, которая в основном использует React для разработки. С командой из нескольких человек и запущенным существующим проектом, с развитием бизнеса и увеличением персонала, вам срочно нужно наладить полный, унифицированный и стандартизированный процесс разработки. наконец, изготовьте леса.
Выберите стек технологий
Для проекта React общий стек технологий обязательно должен учитывать следующее:
- ТС или JS?
- Выбрать крючки, не крючки или гибрид?
- CSS-решение, это предварительная обработка, как Saas или CSS-In-JS, Atom CSS?
- Как выбрать государственное управление?
- Как выбрать маршрут? На самом деле выбора очень мало
В первую очередь, прежде чем рассматривать плюсы и минусы той или иной технологии, нам нужно проанализировать ситуацию в команде.
Например, если нам сейчас нужно решить, что выбрать TS или JS, мы должны сначала рассмотреть, знают ли или разрабатывают проекты TS большинство членов команды. Если большинство членов неквалифицированны и устойчивы к ТС, то сильная ТС неизбежно приведет к снижению эффективности разработки.anyлетать везде. Конечно, если Лидер выдержит кратковременное снижение эффективности, то решение ТС можно ставить на вариант, в противном случае вариант, возможно, придется немного отложить, либо его будут лишь постепенно продвигать в некоторых проектах.
Далее я возьму приведенный выше стек технологий в качестве примера, чтобы проиллюстрировать, какие точки зрения мы должны учитывать при выборе моделей.
Выбрать крючки, не крючки или гибрид?
Затраты на адаптацию в таблице ниже основаны на предположении, что члены команды уже могут писать проекты React с использованием компонентов класса.
| Hooks | Без крючков | смешивание | |
|---|---|---|---|
| Стоимость начала работы | высоко | без | высоко |
| Функциональная возможность повторного использования | высоко | Низкий | середина |
| Читаемость кода | высоко | Низкий | середина |
| Общие дефекты каждого | Ловушка закрытия, неполный жизненный цикл контрастных компонентов | Недостатки класса JS | имеют |
| Стоимость миграции старого проекта | высоко | без | середина |
Выбор хуков на самом деле обсуждался в статьях несколько лет назад, поэтому я не буду здесь рассказывать о преимуществах и недостатках друг друга, а в приведенной выше таблице приведены лишь некоторые распространенные сравнения.
Этот раздел в основном предназначен для того, чтобы дать вам представление, когда мы сталкиваемся с выбором, какие направления следует учитывать.
CSS-схема
| CSS-In-JS | Atom CSS | предварительная обработка | |
|---|---|---|---|
| Стоимость начала работы | высоко | середина | едва |
| Стоимость переопределения стиля | Высокий, требуется доступ к внешнему классу или стилю одного узла. | без | без |
| читаемость кода | высоко | едва | высоко |
| поддержка postcss | Не поддерживается, вы должны использовать свой собственный | служба поддержки | служба поддержки |
| поддержка ССР | Серверная сторона требует написания дополнительного кода | служба поддержки | служба поддержки |
По выбору схемы УСБ автор писал статью еще в начале годастатьяЕсли вы заинтересованы, вы можете прочитать его самостоятельно. В следующих словах автор кратко расскажет об этих схемах.
CSS-In-JS
Автор использует эту программу уже два года, и конкретное использованиеstyled-componentsЭто библиотека (далее sc). В целом, я чувствую, что это решение очень ароматно для React, и оно решает некоторые из традиционных моментов написания CSS, которые я ненавижу, например, написание кучи классов, которые действительно трудно назвать.
С помощью этой библиотеки нам нужно использовать JS для управления CSS, чтобы мы могли в полной мере насладиться преимуществами цепочки инструментов, предоставляемыми JS. Когда в проекте есть неиспользуемые компоненты стилей, ESLint может помочь нам найти эти мертвые коды и удалить их.Эта функция все еще может уменьшить часть размера кода для больших проектов.
Кроме того, очень хорошо решаются проблемы загрязнения стиля, проблем с именами и автоматическим добавлением префиксов. В дополнение к вышесказанному, поговорим о двух вещах, которые нелегко заметить.
Во-первых, это динамическое переключение тем. Поскольку мы пишем CSS через JS, мы можем динамически управлять стилями. Если в вашем проекте много динамических требований к CSS, таких как переключение тем, то это решение будет хорошим выбором.
Еще один момент — загрузка по запросу. Поскольку мы пишем CSS через JS, и в основном используем разделение кода для упаковки на этом этапе, мы можем добиться загрузки файлов CSS по запросу, а не загружать их все сразу традиционным способом (конечно, это можно оптимизировать, но не очень удобно).
После этого я буду говорить о недостатке, и стоимость обучения определенно существует.Это не так хорошо. К тому же есть затраты-часы, у самого СЦ объем файлов, плюс динамически генерируемый УСБ, то это должно иметь потери в производительности. Чем больше проект, тем больше проблема, если у вашего проекта высокие требования к производительности, то вам нужно быть внимательным. Кроме того, поскольку CSS создается динамически, файл CSS нельзя кэшировать, как традиционный CSS. Кроме того, затраты на покрытие стилей также немного выше, чем у других решений, а POSTCSS не поддерживается, а программа SSR требует дополнительных затрат на разработку.
Atom CSS
Читаемость кода плохая, а стоимость обучения невысокая, но при наличии зрелых спецификаций пользовательского интерфейса это решение может предоставить общие стили для повторного использования, тем самым уменьшая размер файлов CSS.
На самом деле автор не испытывает оптимизма в отношении широкомасштабного применения этого решения в отечественных бизнес-командах.Из-за изменений пользовательского интерфейса, вызванных частыми изменениями требований, и у большинства команд пользовательского интерфейса нет зрелой спецификации, эти проблемы значительно увеличат стоимость. использования Atom CSS.
Схема предварительной обработки
Его следует рассматривать как традиционное решение, в нем есть все, а стоимость разработки низкая, есть не что иное, как общая проблема CSS: отлаживать его очень больно.
резюме
В общем, при использовании CSS-In-JS необходимо учитывать стоимость обучения и одобрение членов команды, ведь действительно есть некоторые разработчики, которым не нравится писать CSS таким образом.
Atom CSS должен иметь набор зрелых спецификаций UI, иначе UI будет часто меняться по мере изменения требований, поверьте, его точно сожгут.
Про схему препроцессинга и говорить нечего, старт почти не требует затрат, а код прост в сопровождении. Если членам команды не нравится CSS-In-JS и у них нет набора зрелых спецификаций пользовательского интерфейса, выберите этот вариант.
Как выбрать государственное управление?
Вариантов управления состоянием действительно слишком много.Помимо привычных Redux и mobx, есть масса конкурирующих продуктов, таких как:
- xstate
- Recoil
- pmndrsДомашний зустанд, валтио, йотаи
- Кроме того, существует множество нишевых продуктов.
Когда мы выбираем управление состоянием, первым шагом должно быть рассмотрение того, нуждается ли проект в управлении состоянием.На самом деле большинству проектов требуется только взаимодействие между компонентами, а не управление. Или на самом деле, когда вы думаете, нужно ли проекту управление состоянием, в основном оно не нужно на данный момент. Потому что вы, возможно, вообще не сталкивались с проблемами, которые решает управление состоянием, но просто чувствуете, что взаимодействие между компонентами проблематично.
Если ваш проект еще не дошел до уровня, когда требуется управление состоянием, рассмотрите возможность выбора общей библиотеки состояния (что-то вродеhox) плюс хуки, на самом деле, это решение в принципе может покрыть большинство проектов, а код, связанный с состоянием, написанный не так просто срать.
Если проекту действительно нужно управление состоянием, постарайтесь не думать о вещах, связанных с технологиями, а выберите то, что всем знакомо, и используйте это напрямую.. Поскольку управление состоянием слишком просто, чтобы написать гору дерьма, мы, Барабара, сравнили кучу вещей, связанных с технологиями, и, наконец, если мы выберем относительно продвинутый, но незнакомый продукт, то гора дерьма в конце концов должна быть неизбежна.
Как выбрать маршрут?
На самом деле, я лично считаю, что выбора для роутинга не так уж и много.Ведь места для выбора в принципе нет.Какой бы выбор не повлиял на разработку,так что выбирай что хочешь.
разное
В дополнение к техническому выбору, упомянутому выше, у нас также могут быть дополнительные технические требования в соответствии с различными проектами, такие как одиночное тестирование и так далее.
одиночный тест
Бизнес-команда не пишет много отдельных тестов, особенно связанных с пользовательским интерфейсом. Тем не менее, мы можем согласиться на следующий лучший вариант и заказать тесты функций инструмента или некоторых ключевых узлов, чтобы улучшить общее качество кода.
Если функция инструмента проверяется, перейдите непосредственно кJestилиMochaЭто нормально, это всего лишь утверждение. Если вы хотите протестировать пользовательский интерфейс, тоenzymeтак же какreact-testing-libraryтакже имеет важное значение. Наконец, если вы все еще хотите автоматизировать весь тест, перейдите кcypressБар.
Кроме того, я ранее писалодно тестовое изделие, и заинтересованные читатели могут прочитать его сами.
резюме
На самом деле при выборе технологий контент, связанный с технологиями, скорее всего, будет рассматриваться в последнюю очередь, а перед этим нам необходимо взвесить внешние факторы, такие как команда, продолжительность проекта и требования к проекту.
Наконец, что касается выбора каждого стека технологий, вы можете просмотреть то, что сделал Yunqian.склад, он должен быть достаточно всеобъемлющим.
Инженерная конфигурация
Инженерная конфигурация в проекте — очень важная часть, эта часть контента должна быть как можно меньше настроена для разработчиков, в обычных сценариях ее нужно использовать «из коробки».Часть конфигурации сильного контроля.
Автор пообщался с некоторыми фронтенд-разработчиками в небольших компаниях и узнал, что их разработка на самом деле довольно запутанная. Например:
- Конфигурация проекта отличается для каждого проекта, что воплощается в проблемах путаницы в конфигурации Webpack, бесполезности ESLint и путанице в формате кода.
- Нет спецификации для отправки коммита, и никто не проверяет код.
- и т.п. . .
Если вышеуказанные проблемы случаются с вашей командой, которая читает статью, вы можете попытаться улучшить ее в соответствии с приведенными ниже идеями.
Для проекта необходимо следующее:
- Конфигурация билдера, обычно Webpack в приложении
- Вавилонская конфигурация
- конфигурация ТС
- Конфигурация ESLint
- Более красивая конфигурация
Касательно вышеуказанного содержания, лично я считаю, что помимо второго и третьего пунктов необходимо строго контролировать и другие пункты.
Для Webpack все знают, что настройка очень хлопотная, но немалая часть конфигурации должна быть общей в каждом приложении. Мы можем извлечь эту часть общей конфигурации и сделать внутреннюю предустановку, например@babel/preset-envТакой же. Такой подход упрощает настройку, тем самым не позволяя пользователям возиться с Webpack для каждого проекта. В то же время при обновлении Webpack в будущем пользователям не нужно обращать внимание на изменение общей конфигурации, а нужно только адаптировать свою новую конфигурацию.
Тогда для ESLint и Prettier необходим строгий контроль, и конфигурация инкапсулируется непосредственно для пользователей.requireПросто сделай это. Таким образом, можно избежать ситуации, когда ESLint закрыт, а формат кодировки полностью изменен для другого проекта, такого рода проблема на самом деле является сокрушительным ударом по качеству кода, и все будут ломать банку и писать код. .
В общем, для инженерной конфигурации нам лучше позволить пользователям как можно меньше касаться конфигурации и сосредоточиться на бизнес-коде. Места, которые можно строго контролировать, должны строго контролироваться, и качество кода всей команды будет улучшено. Конечно, мы не можем принудительно контролировать все конфигурации, в некоторых местах нам все еще нужно открыть дыру для пользователей, чтобы они могли настраивать/объединять элементы конфигурации, такие как Webpack.
Структура каталогов
Хороший каталог проекта может улучшить ремонтопригодность проекта, иначе код будет неорганизованным, и вы можете написать его хорошо, но это будет большой головной болью для коллег, которые возьмут на себя управление.
Автор примерно делит каталог проекта на следующие разделы:
- страницы, страницы, где каждая папка разделена на функциональные модули
- компоненты, компоненты, разделенные на общие и бизнес-компоненты
- сервисы, где речь идет о бэкенде
- хранилище, связанное с логикой управления состоянием, если необходимо
- утилиты, константы, служебные функции и т. д.
- типы, потребности проекта TS, тип хранилища
- активы, статические ресурсы, такие как изображения и svg
- тесты, связанные с тестами, если необходимо
Согласно приведенной выше классификации, наш общий каталог проектов будет выглядеть так:
└── /src
├── /pages
├── /components
├── /services
├── /store
├── /utils
├── /types
├── /assets
├── /tests
├── index.ts
└── App.ts
В дополнение к вышесказанному, в соответствии с нашим различным выбором CSS и инженерными решениями, соответствующие файлы также будут разными.
встроенный в леса
Леса просто помогают намgit cloneПосле того, как приходит проект инициализации, самые основные леса можно условно разделить на две части:
Инженерная конфигурация и код шаблона были рассмотрены выше, вы можете собрать такой набор вещей под свое дело, но этого недостаточно для создания полезного скаффолда.
Например, что, если некоторым предприятиям необходимо провести один тест? Нужно ли бизнес-партнерам самостоятельно выполнять множество настроек?
Например, в зависимости от бизнеса, шаблоны могут немного отличаться.На данный момент мы должны создать новый набор шаблонов или что мы должны сделать?
Поэтому для скаффолдинга нам нужно добавить некоторый необязательный контент поверх необходимой инженерной конфигурации. Например, если бизнес-сторона считает, что проекту нужен один тест, то при инициализации проекта один тест может быть автоматически добавлен в конфигурацию, необходимую для одиночного теста.
Затем из-за разных предприятий могут быть различия в коде шаблона.В это время мы можем решить, разделить ли набор шаблонов или поддерживать компиляцию на исходном шаблоне в зависимости от ситуации, чтобы определить окончательный вывод шаблона. в соответствии с вводом пользователя.
Делая все вышеперечисленное хорошо, мы можем сделать леса, которые просты в использовании и подходят для бизнеса нашей команды.
наконец
В статье нет кода, но в основном рассказывается о том, как проектировать React-проект с нуля с точки зрения автора, что такое выбор стека технологий, как его использовать в разработке и структура каталогов проекта. и, наконец, как сделать полезные леса.
Добавить Автора
склад:Github
Нет публики:Передняя часть это весело
Специальное заявление: Нелегко быть оригинальным, и перепечатка или плагиат не допускаются без разрешения.Если вам нужно перепечатать, вы можете связаться с автором для получения разрешения.