JavaScript-библиотека для создания интерфейсов
Казалось бы зачем рассказывать о Redux в 2020ом году. Ведь есть столько замечательных альтернатив на поприще стейт-менеджеров (например). Ведь есть с десяток причин не любить Redux, о которых исписано немало статей, и прозвучало немало докладов. Однако кое-чего у него не отнять — на нём можно написать большой, функциональный, поддерживаемый и быстрый веб-сайт. Ниже я расскажу о приёмах, которые помогают это сделать с использованием react-redux. Интересно? Добро пожаловать под кат.
inner_key, которая будет необходима нам для отрисовки уникальных ключей для каждого отдельного дела (в списке повторяющихся элементов React нужен уникальный ключ на каждый элемент для его обработки в Virtual DOM. Если это по прежнему вызывает у вас вопросы, вам стоит изучить эту статью).
Этот пост является вторым в серии статей об авто-трекинге — новой системе реактивности в Ember.js. Я также обсуждаю концепцию реактивности в целом, и как она проявляется в JavaScript.
От переводчика: Крис Гарретт — работает в компании LinkedIn и является одним из core-контрибьюторов js-фреймворка Ember. Он принимал активное участие в создании нового издания фреймворка — Ember Octane. Одним из краеугольных камней этой редакции является новая система реактивности на основе автоматического отслеживания (autotracking). Несмотря на то, что его серия написана для Ember-разработчиков в ней затрагиваются концепции, которые полезно знать всем веб-программистам.
Для большинства людей факторинг – услуга непонятная. По факту — это финансирование поставок компаний, работающих с отсрочкой платежа.
Предположим, вы небольшой производитель круп. Вы отгрузили товар в торговую сеть, но деньги получите в среднем через 60 дней после отгрузки. Многим компаниям ждать столько не под силу: ту же зарплату сотрудникам нужно платить уже сейчас. Одно из решений — факторинг. После заключения договора факторинга вы можете получить финансирование любой поставки. Достаточно после отгрузки товара отправить фактору подтверждающие документы (счета-фактуры, накладные, акты). Фактор верифицирует поставку у вашего покупателя и перечисляет вам деньги за товар, за вычетом собственной комиссии.
В сделке участвуют покупатель, поставщик и фактор, которые подписывают множество бумаг, уведомлений. Раньше взаимодействие с клиентом собиралось как паззл из разных кусочков: например, подписание договоров происходило при помощи сторонних операторов электронного документооборота, верификация поставок — пересылкой по e-mail excel-файлов, а в личном кабинете на сайте фактора поставщик мог посмотреть лишь статистику по сделкам. Было неудобно, трудоемко – и нам, и клиенту. Надо было собрать всё это в одну систему.
В статье речь идет о state colocation, то есть о совместном размещении состояний, этот термин можно было бы еще перевести как стейт колокейшн или стейт колокация.
Одной из основных причин замедления работы React приложения является его глобальное состояние (global state). Я покажу это на примере очень простого приложения, после чего приведу более близкий к реальной жизни пример.
Вот простенькое приложение в котором можно ввести имя для собаки (если окно не работает, вот ссылка):
Если вы поиграете с этим приложением то вскоре обнаружите что оно очень медленно работает. При взаимодействии с любым полем ввода возникают заметные проблемы с производительностью. В такой ситуации можно было бы использовать спасательный круг в виде React.memo и обернуть им все компоненты с медленным рендером. Но давайте попробуем решить эту проблему по другому.
Вот код этого приложения:
Когда я заглядываю в файл {domain}/selectors.js в больших проектах на React/Redux, с которыми работаю, я часто встречаю огромный список redux-селекторов подобного вида:
getUsers(state)
getUser(id)(state)
getUserId(id)(state)
getUserFirstName(id)(state)
getUserLastName(id)(state)
getUserEmailSelector(id)(state)
getUserFullName(id)(state)
…На первый взгляд использование селекторов не выглядит чем-то необычным, но с опытом мы начинаем понимать — селекторов может накопиться слишком много. И кажется, мы дожили до этого момента.
В настоящее время я тестирую реализацию кода. Такие тесты ломаются каждый раз после рефакторинга, особенно в компонентах пользовательского интерфейса. В итоге я провожу кучу времени, копаясь в файлах .test.js, паралельно приследуюя магическую цифру в 80% для Test Coverage.
При написании любого типа тестов, включая модульное тестирование, я должен меньше думать о коде который я тестирую, а больше о том, что делает данный код. Это означает писать тесты, имитирующие поведение пользователя. Даже на самом низком уровне.