Вы знаете, когда проекту необходим HTML и CSS, ведь он целиком из них и состоит. Ясно для чего вы добавляете JavaScript — вам нужна интерактивность или какая-то функциональность, которую может предоставить только JavaScript. Вполне понятно зачем нам нужны библиотеки. Мы подключали jQuery, чтобы помочь нам упростить работу с DOM, Ajax и справиться с кросс-браузерными проблемами с помощью JavaScript.
Поскольку потребность в этих библиотеках гаснет, и мы наблюдаем массовый рост новых фреймворков, кстати в данной статье есть примеры известных приложений, исполюзующих React, но я бы сказал, что не совсем понятно, когда эти фреймворки нужно использовать. В какой момент нам нужен тот же React?
Я просто собираюсь использовать React в качестве альтернативы для своего рода больших JavaScript-фреймворков: Vue, Ember, Angular, Svelte … и так далее. Я понимаю, что они все далеко не одинаковые, но в каких случаях их использовать, я нахожу одинаково туманным.
Вот мои список «за» и «против».
Большое количество состояний (state).
Слово «состояние» или state тоже немного туманное. Представьте себе следующие вещи:
- Какой элемент навигации активен
- Будет ли кнопка отключена или нет
- Какие разделы аккордеона расширены
- Момент загрузки области
- Пользователь, вошедший в систему, и категория, к которой он принадлежит
- Опубликована ли статья, над которой работает пользователь, или же это черновик
React не помогает вам организовывать эти состояния, он просто говорит: я знаю, что вам нужно иметь дело с состоянием, поэтому давайте просто назовем его state и будем иметь программные способы установки и получения этого состояния.
Долгое время мы рассматривали DOM как единственный источник данных. Например, вам нужно знать, может ли форма на вашем сайте быть отправлена. Скорее всего вы сделаете такую проверку: $(«.Form input[type=’submit’]).(«:Disabled»), потому что вся логика, которая решает вопрос о том, может ли форма быть отправлена в конечном итоге это — атрибут Disabled кнопки отправки. Или например, получить имя автора первого комментария в статье. Наверняка вы напишете подобное $(«.Comments>ul>li:first> h3.comment-author).text(), потому что DOM единственное место, в котором есть эта информация.
React говорит нам:
- Давайте начнем думать обо всем этом как о событиях (state).
- Кое-что я улучшу: state — это часть JSON, и с ним легче работать и который возможно приятнее совмещать с вашим бэкендом.
- И еще одно улучшение: вы строите свой HTML, используя кусочки этих state, и вам не придется иметь дело с DOM напрямую, я беру все это на себя (и, вероятно, сделаю эту работу лучше и быстрее чем вы).
Борьба с «Спагетти-кодом»
Спагетти-код — это запутанный и трудный для понимания код, он назван так, потому что ход его выполнения похож на миску спагетти, тоесть извилистый и запутанный (wikipedia).
Снова представьте себе форму на вашем сайте. В ней есть код который обрабатывает входные данные. Пусть будет числовое поле, которое при изменении отображает результат некоторого вычисления рядом с ним. Форму нужно подтвердить, а данные должны пройти валидацию, поэтому этот код должен находиться в библиотеке в отдельном месте. Возможно вы сделайте форму неактивной, до тех пор пока не загрузятся все скрипты JavaScript, и этот код хранится где-то отдельно. Когда форма отправлена, вы получаете данные обратно, и эти данные опять же нужно обрабатывать. Во всем этом можно быстро запутаться. И как новый разработчик на проекте, глядя на эту форму, должен разобраться во всем, что происходит?
React поощряет распределение кода на модули. Таким образом, эта форма, скорее всего, либо будет самостоятельным модулем, либо будет состоять из более мелких модулей. Каждый из них будет обрабатывать логику, которая имеет прямое отношение к форме.
React говорит: хорошо, вы не собираетесь следить за изменениями и содержанием DOM напрямую, потому что DOM принадлежит мне, и вы не можете напрямую работать с ним. Почему бы вам не начать думать об этих вещах как о части состояния, когда вам нужно изменять эти состояния, а я разберусь с остальным, представлю то, что должно быть представлено.
Следует сказать, что сам React полностью не исключает спагетти-код. Вы все еще можете иметь state в самых странных местах, непонятным образом называть переменные и прочее.
По моему ограниченному опыту, именно Redux — это то, что действительно убивает спагетти (или съедает напрочь если хотите). Redux говорит: я буду обрабатывать все важные состояния, полностью, глобально, а не модуль за модулем. Если вам нужно изменить state, то нужно провести определенную церемонию или выполнить определенные правила. Существуют «редюсеры» (reducers) и «диспатчеры» (dispatch) и тому подобное. И все они следуют «церемонии проведения».
Множество манипуляций с DOM.
Ручные манимуляции с DOM, вероятно, являются самым ярким показателем спагетти-кода.
React говорит: вы не можете напрямую обращаться к DOM. У меня есть виртуальный DOM, и я занимаюсь этим. События привязаны непосредственно к элементам, и если вам нужно сделать что-то сверх того, что можно напрямую обработать в этом модуле, вы можете по определенным правилам обращаться к модулям более высокого порядка, но тут все просто и отслеживаемо.
Запутанное управление DOM — это другое. Представьте приложение чата. Новые сообщения чата могут появиться, потому что база данных в реальном времени имеет новые данные от других пользователей, одновременно поступают некоторые новые данные. Или вы набрали новое сообщение сами! Или страница загружается в первый раз, и старые сообщения вытягиваются из локального хранилища данных, поэтому у вас есть что посмотреть прямо сейчас. Тут отследить логику будет гораздо сложнее.
Просто так. Потому что это тренд.
Изучать чтото ради обучения чему-то это конечно здорово. Но все же к разработке проекта на продакшен нужно подходить более внимательно.
Например, если вы пишете блоговый сайт, то React, со своими технологиями и зависимостями не будет лучшим выбором, поскольку эти технологии попросту не требуются.
Блог представляющий собой SPA («Single Page App»), одностраничное приложение не требующее перезагрузки страниц браузером, до сих пор является пустой нишей. В свою очередь, CMS веб приложения, для создания блогов например, будут отличным выбором в сторону React.
Мне просто нравится JavaScript и я хочу писать все на JavaScript.
Только с недавних пор веб-истории стало возможным никогда не покидать JavaScript. У вас есть Node.js для выполнения кода на стороне сервера. Есть множество проектов, которые вытаскивают CSS из миксов и обрабатывают стили с помощью JavaScript. И с React-ом ваш HTML тоже хранится в JavaScript.
Это все замечательно, но опять же, только потому, что вы возможно кое-чего не понимаете. Не во всех проектах это требуется, далеко не все задачи на сегодняшний день JavaScript, а вместе с ним и React, способен решать.
Это то, что я знаю.
Вы учитесь. Потрясающе. Все учатся. Продолжайте и вы. Чем больше вы знаете, тем более объективнее вы можете решить, какие технологии использовать.
Но иногда вам необходимо использовать тот язык, те инструменты и те технологии в которых вы уже хорошо поднатаскались, если вы работаете с React, то я не буду тут вас переубеждать.
Потому что есть специалисты.
Не каждый может заранее сказать какие именно технологии нужно использовать в том или ином проекте. Это приходит со временем. Я лишь хочу сказать, что кто-то выбирает тот или иной фреймворк для своего проекта лишь потому, что имеются специалисты (специалист), знающие этот фреймворк и умеющие с ним работать.
Выбрать React для своего проекта, потому что у вас есть специалисты по React, в этом нет ничего плохого. Как знать, возможно как раз он идеально подойдет для вашего проекта.
Не совсем точный перевод статьи css-tricks.com