Создание архитектуры вашего приложения React.

В наши дни, когда MVC чувствует себя из эпохи динозавров. Наши API обслуживают несколько клиентских приложений, и большая часть бизнес-логики перенесена в наши клиентские приложения. Front-end разработка - это гораздо больше, чем просто красиво закодированный интерфейс, это много программирования, иногда архитектура может быть сложной, и даже обслуживание нашего веб-приложения может быть не таким простым, как отправка вещей через FTP.

В этой статье предполагается, что у вас уже есть некоторый опыт создания хотя бы небольших приложений React, и вы собираетесь принять более серьезные архитектурные решения в своем (первом) крупномасштабном приложении. React - отличный инструмент для создания чего-то экстраординарного, однако я часто вижу, как разработчики пытаются использовать React везде, где это возможно. Если вы собираетесь создать что-то маленькое, что не требует слишком большого количества серверных сервисов, возможно, презентацию (целевые страницы) вашего продукта, я полностью рекомендую Webflow, чтобы сэкономить ваше время на создании ваших намерений путем проектирования с минимальным кодированием и развертыванием. знания!

Итак, вы или ваша компания только что решили начать большой (коммерческий, общедоступный) проект и решили использовать React. Вы, вероятно, уже провели некоторое исследование, иначе вы бы не выбрали React, но есть еще много решений, которые нужно использовать в своем стеке. React - это просто библиотека представлений, и здесь много недостающих частей. Управление состоянием, маршрутизация, локализация, стили и интерфейс, развертывание,… Вам нужны PWA, SSR?

(Не) к счастью, когда дело касается архитектуры стека React, существует большая свобода. Если вы знаете, что делаете, вы можете настроить его менее чем за день. Или вы можете бороться неделю, пока все не наладится. Здесь я собираюсь поговорить об идеальном сценарии, поскольку одна статья не может охватить все подводные камни и отдельные случаи, которые могут повлиять на решения.

Перед тем, как начать, сначала проанализируйте и постарайтесь не усложнять

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

Чтобы успешно выпустить вашу самую первую версию приложения (MVP), вы должны быть простыми, использовать только необходимые инструменты и библиотеки. Добавление дополнительных инструментов и библиотек, которые могут быть полезны в будущем, просто усложняет вашу разработку и замедляет ее. Каждый разработчик с энтузиазмом пробует что-то новое, однако я не думаю, что начало большого проекта - подходящее время для этого.

В моей самой первой статье я написал несколько мыслей о разработке вашего приложения с точки зрения UX, хотя оно предназначено для дизайнеров, оно написано с точки зрения разработчика / разработчика продукта. Хороший UX нужен даже для разработки.

Масштабируемость команды

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

Javascript - это страна безумцев, поэтому важны общие шаблоны и передовой опыт. Теоретически это должно помочь с ясностью кода. Наверняка всего никто не знает, но имейте в виду. Вы не пишете код исключительно для себя. Также… Что вы думаете о коде, который вы написали год назад? Иногда у меня болит голова, поэтому я хочу убедиться, что после прочтения моего кода это будет наименее болезненно, как это может быть для других! Конечно, инструменты разработки, такие как eslint и flow (или, если вам нравится машинописный текст), помогают поддерживать кодовую базу в большой команде.

Выбор правильных библиотек для вашего проекта javascript. Какой из них лучше?

Это библиотека, которую вы и ваша команда знаете лучше всего и с которой вам удобно работать. Шутки в сторону. Вы хорошо знаете Redux? Затем используйте Redux для управления состоянием. Вам нравится MobX? Тогда используйте MobX. Стек хорош настолько, насколько хорош разработчик (и), работающий над ним. Я не говорю, что вам не следует использовать что-то новое, мне нравится изучать новое, как и вам, но лично для меня эти новые вещи относятся к каким-то внутренним или личным проектам, где ошибки и небольшие знания допустимы. Изучение новой библиотеки - это не только чтение документации, иногда в этих библиотеках используются совершенно разные подходы и шаблоны, и на освоение всегда требуется время.

Все еще чувствуете, что должны использовать то, о чем слышали? Одна или две новинки - это нормально, но убедитесь, что это не повлияет на качество проекта. И, нравится вам это или нет, вам придется думать и о других людях. Хороший разработчик умеет программировать. Отличный разработчик знает, как работать в команде. А совместное использование знаний намного важнее для вашей команды и бизнеса. Использование общих шаблонов и лучших практик не для удовольствия, и то же самое применимо, когда вы принимаете решение о своей архитектуре. Общие технологии (не устаревшие!) Могут быстро ускорить вашу разработку при росте команды.

Мой выбор библиотек при создании нового проекта

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

Стек разработчика и наборы инструментов - razzle или create-react-app

Настроить свой проект с нуля с помощью webpack и babel, безусловно, здорово и сложно, но в будущем вы не захотите тратить лишние часы на его обновление. К счастью, в экосистеме React есть большое и полезное сообщество, которое для начала создало отличные инструменты. Не стыдно воспользоваться тем, что построено. Это доказано и есть много ответов на ваши вопросы.

Если мне нужен сервер, я использую razzle (или after.js), который мне очень нравится из-за его простоты, настраиваемости и скорости. В качестве альтернативы вы можете попробовать next.js, но для моих нужд он слишком строг или ограничен, когда дело касается асинхронных задач.

Если я знаю, что мне не нужен сервер или рендеринг на стороне сервера, я всегда использую create-response-app. Помимо стандартных задач сборки, он также имеет встроенные полезные функции, такие как PWA.

Библиотека пользовательского интерфейса

Это очень сложная часть, на которую у меня нет ответа. Существует множество UI-библиотек, таких как material-ui или ant design. Многие из них могут добавить некоторую сложность, например, стили и тематику, и вам также придется немного узнать о библиотеке.

Так что бы я сделал? Вы можете оказаться, что вы и ваша команда окажетесь в ситуации, когда у вас нет опытного UI / UX-дизайнера. Если бы это был я, я бы уже чувствовал себя довольно некомфортно, потому что для меня хороший дизайн, хороший UX и взаимодействие так же важны, как и все остальное. В этом случае я бы, вероятно, использовал какую-нибудь библиотеку с большим количеством исследований.

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

По многим причинам, указанным выше, я решил принять вызов моего друга @janlosert, который также является отличным дизайнером, и мы выпустили Dashboard UI Kit, который также включает более 70 стилизованных компонентов. Вы можете проверить наши 15 предварительно закодированных превью страниц и компоненты здесь.

Обновление 26 марта 2020 г .: Мы выпустили основные компоненты на github и npm в виде библиотеки, которую может установить каждый!

Управление состоянием - Redux

Выбрать redux для меня нетрудно. Идея проста и хорошо согласуется с подходом функционального программирования, который прост и понятен. Как только вы поняли идею, вы можете попробовать множество плагинов и промежуточных библиотек, таких как redux-thunk или его улучшенный клон redux-thunker или redux-prom-middleware.

Локализация - react-i18next

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

Маршрутизация - реактивный маршрутизатор

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

Сводка вариантов

Как видите, вы, вероятно, уже слышали об этом раньше. И у этих пиков есть общие доводы. Они хорошо известны в сообществе, и, скорее всего, вы найдете много людей в вашей команде, которые тоже это знают. Совершенно нормально использовать то, что делают все, потому что, по правде говоря, бизнес всегда на первом месте. А с точки зрения бизнеса вам нужен надежный продукт и команда, которая может расти вместе с вашими целями.

Огромным преимуществом для разработчиков также является тот факт, что сообщество настолько велико, что, когда вы боретесь с проблемой, вы, скорее всего, найдете ответ, будь то stackoverflow или страницы github. Хорошая документация важна для разработки, и именно здесь сияют широко известные библиотеки.

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

Резюме

Я люблю экспериментировать с новыми вещами, и обучение всегда подталкивает меня вперед. Будь то разработка, продукт или бизнес, всегда есть возможность продвинуться на несколько шагов дальше. Как разработчик, я всегда в восторге от новых технологий, однако, имея перспективу в качестве владельца продукта, также важно понимать потребности бизнеса, компании / стартапа, частью которого вы являетесь. С учетом сказанного, я не думаю, что вам следует экспериментировать (слишком много) с важными или критически важными приложениями. Истинный навык ведущих или старших разработчиков - это знать, какой инструмент использовать в той или иной ситуации, и получать от него большую часть, не забывая при этом о возможных рисках как для развития, так и для бизнеса.

Удачного кодирования!

📝 Прочтите этот рассказ позже в Журнале.

🗞 Просыпайтесь каждое воскресное утро и слышите самые интересные истории, мнения и новости недели, ожидающие в вашем почтовом ящике: Получите примечательный информационный бюллетень›