Немного контекста

Справиться с этим было сложно. Я не фанат фронтенд-разработки, но я сделал это довольно много. Я никогда не беспокоился о том, чтобы страница выглядела красиво, а вместо этого хорошо работала. Так что вы, вероятно, никогда не увидите, чтобы я говорил о CSS или SASS. Я сторонник использования таких вещей, как Bootstrap, Foundation или Google Material Design (не уверен в этом), чтобы страница не выглядела уродливо.

Поэтому я не так давно начал проект. Этот проект называется Карбоно, и, честно говоря, я его уже давно начал. Все было так суматошно, что все было забыто. Когда я забрал его обратно, я не был доволен ничем из того, что я там увидел. Ни backend, ни frontend не были чем-то, чем я бы гордился.

Знаешь? Предполагается, что речь идет о деньгах, но для меня это больше проблема. Бэкенд я переделал очень классно (но эта статья не об этом), и фронтенд тоже должен был быть классным. Фронтенд изначально был сделан с AngularJS и RequireJs. Я мог бы продолжить, но, как я уже сказал, это больше связано с вызовом. Что это была за удивительная технология, которую все использовали? Реагировать! Изучаем React!

В то время я (сам) не осознавал, что технология (библиотека, фреймворк и т. д.) мне нравится, когда я понимаю ее философию. Я был из тех программистов, которые пытались привести ДРУГУЮ философию в соответствие с новой технологией, которую едва открывали. Подгонка мышления AngularJS к проекту React просто неверна, кто бы ни переходил с AngularJS на React, пожалуйста, не пытайтесь заставить проект React мыслить в духе AngularJS. Вы увидите, у них разные мотивы, и начнем с того, что AngularJS — это фреймворк, а React — это библиотека. Вы должны использовать реакцию со многими другими библиотеками, такими как Redux, Lodash, RxJs и т. д.! Но это не сравнение этих двух технологий. При этом я, наконец, понял это, поэтому я искал фреймворк, использующий React, и так появился Flux. Flux оказался просто набором идей о том, как разрабатывать веб-приложения, но не имел четкой реализации. Затем появился Йоман и тонко намекнул, что многие используют что-то под названием Redux. А я посмотрела и полюбила. Именно тогда я, наконец, начал понимать эти 3 технологии. Итак, поехали!

Редукс

Redux — это просто контейнер состояния для веб-приложения с очень ясной и простой для понимания философией. Для тех, кто любит функциональное программирование, Redux — это наслаждение! Почему? потому что его переходы состояний представлены функцией… функцией редукции (именно поэтому она называется Redux). Если вы когда-либо сокращали список, вы знаете, что сокращаете элементы в списке, чтобы получить результат, верно? Что ж, по этой аналогии элементы в списке — это действия в веб-приложении, а результат — текущее состояние приложения. Если новое действие сокращается, создается новое состояние. Легко да? В нотации Scala это будет выглядеть так:

(Состояние,Действие)=›Состояние

В Redux, в отличие от Flux, всего один магазин. И есть только один способ изменить состояние этого хранилища — отправить действие. Как вы уже догадались, хранилище создается с помощью функции сокращения (и начального состояния). Куда поместить асинхронные действия, такие как вызовы API? ну, Redux ясно дает понять: не в функции сокращения, эта функция всегда синхронна. Но вы можете запускать задачи, которые в конечном итоге отправляют множество действий, таких как «начал загрузку элементов», «получил элементы из асинхронного действия».

Реагировать

Реакция была сложной для понимания. В основном потому, что я сначала понял Redux, и потому что я пришел из Angular. Основная концепция, которую нужно понять, это НЕТ ДВУХСТОРОННЕЙ ПРИВЯЗКИ. Вторая концепция, которую нужно понять: «забудьте о манипуляциях с DOM, вы всегда визуализируете все это в виртуальном доме, а react будет обрабатывать манипуляции с домом, и он будет делать это оптимизированным способом». Третье лучше сказать шрифтами.

type Component = (Props, State) => DOM

Или, скажем так, словами. Компоненты реакции — это просто функция рендеринга, которая использует предоставленные реквизиты и текущее состояние для создания DOM. Если вы измените состояние, новый рендер... если вы измените реквизит, новый рендер! Вот и все.

Третье мне было неприятно. В основном, опять же, потому что я сначала изучил Redux, и в туториалах они используют то, что называется компонентами React без состояния. Я столкнулся с этим при попытке открыть и закрыть модальные окна с помощью Redux. Нехорошо иметь логическое значение в состоянии Redux для каждого модального окна, которое может существовать в приложении. Вы просто не хотите загрязнять глобальное состояние такими атрибутами, как «isFilePickerForStockModalOpen». Некоторые свойства состояния всего приложения просто не заслуживают того, чтобы быть в Redux Store. Вот когда состояние компонентов React пригодится. Там вы могли бы иметь этот атрибут, не загрязняя Redux Store… отлично, да?

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

Вебпак

Я любил этот. И теперь, когда я думаю об этом. В какой-то момент мой опыт фронтенд-разработки взлетел до небес из-за простого любопытства и перфекционизма (я знаю, что это плохо для предпринимателей, но я отказываюсь это менять). Я начал использовать RequireJS, потому что все говорили, что это круто, и мне это нравилось… или, по крайней мере, я его понимал. Когда я начал использовать Webpack, я даже не знал, что он делает, и в какой-то момент я просто хотел использовать Webpack, как если бы это был RequireJS. Вы увидите, что я довольно часто совершаю эту ошибку. В какой-то момент я сказал себе: «Я ненавижу Йомена, это дерьмо дает тебе все, что тебе нужно, но ты понимаешь дерьмо», поэтому я решил понять Webpack, прежде чем продолжать проект… и я его понял. Все в нем основано на простой идее: «Webpack знает, как создать пакет только с учетом входного js-файла, который зависит ТОЛЬКО от других js-файлов» (на самом деле их больше, но это важнее для меня). Все, что выходит за рамки этой идеи, может подойти, если вы преобразуете это в Javascript (они называются загрузчиками). Таким образом, загрузчики берут файл в другом формате и обрабатывают его для создания Javascript. Таким образом, вы можете сделать файл js зависимым от файла SASS. Вы даже можете сцепить загрузчики, которые производят другие виды форматов, единственным ограничением является то, что последний загрузчик должен возвращать Javascript. Существует также концепция плагинов; они используются для постобработки пакета javascript, созданного Webpack. Такие вещи, как linting, uglification и minification, создаются плагинами. Ну это все.