Рубрика «redux» - 10

Мысли о том, какие требования выдвигает Redux, как задумано использование Redux и что возможно с Redux.

Введение

Я потратил много времени, обсуждая онлайн паттерны использования Redux, была ли это помощь тем, кто изучает Redux в Reactiflux каналах, дискуссии о возможных изменениях в API библиотеки Redux на Github'е, или обсуждение различных аспектов Redux'а в комментариях к тредам на Reddit'е или HN (HackerNews). С течением времени, я выработал свое собственное мнение о том, что представляет собой хороший, идиоматичный Redux код, и я хотел бы поделиться некоторыми из этих мыслей. Несмотря на мой статус мейнтейнера Redux'а, это всего лишь мнения, но я предпочитаю думать, что они являются достаточно хорошими подходами :)

Redux, в своей сути, невероятно простой паттерн. Он сохраняет значение, выполняет одну функцию для обновления значения когда это необходимо, и уведомляет любых подписчиков о том, что что-то изменилось.

Несмотря на эту простоту, или, возможно, вследствие ее, существует широкий спектр походов, мнений и взглядов о том, как использовать Redux. Многие из этих подходов широко расходятся с концепциями и примерами из документации.

В то же время, продолжаются жалобы на то, как Redux «заставляет» вас делать вещи определенными способами. Многие из этих жалоб на самом деле включают концепции связанные с тем, как Redux обычно используется, а не фактическими ограничениями наложенными самой библиотекой Redux. (Например, только в одном недавнем HN треде я видел жалобы: «слишком много шаблонного кода», «константы action'ов и action creator'ы не нужны», «я вынужден редактировать слишком много файлов чтобы добавить одну фичу», «почему я должен переключаться между файлами чтобы добраться до своей логики?», «термины и названия слишком сложны для изучения или запутанны», и слишком много других.)

Читать полностью »

Мы хотим создать пакет, который позволит нам избавиться от постоянного создания однотипных reducer'ов и action creator'ов для каждой модели, получаемой по API.

Первая часть — вот эта вот статья. В ней мы создали конфиг для нашего будущего пакета и выяснили, что он должен содержать action creator, middleware и reducer. Приступим к разработке!

Читать полностью »

image

На дворе 2017 год, а это значит, что я уже как полтора года занимаюсь мазохизмом.
Два года назад я был весел и жизнелюбив, сейчас не хочется ни шутить ни развлекаться. За два года redux сделал меня фаталистом. Моя уверенность в ужасном будущем так называемого “frontend” увеличивается с каждым днём. В конце концов, сбербанк сделал redux основой своего стека, а эти ребята хорошего не выберут. Шутка! Я уверен, там работают замечательные специалисты.
Читать полностью »

И в чем же проблема?

Я начал изучать React и Redux не так давно, но он уже успел изрядно потрепать мне нервы. Буквально над каждым действием приходится задумываться — почти никакие изменения в коде невозможны без того, чтоб что-то оторвать. Чтоб просто получить список постов по API и вывести их, надо, пожалуй, написать не меньше сотни строк кода — создать корневой контейнер, создать store, добавить action для запроса к API, для успешного результата запроса, для неудачного результата запроса, создать action-creators, сматчить action-creators и props, сматчить dispatch и props, написать reducer на каждый action… Ух, продолжать не хочется. И все это мы должны делать заново для каждого веб-приложения — крайне нерациональная трата сил программиста.

Да, можно сказать новичку: "Смотри, тут десяток пакетов, которые могут сделать каждое действие из этого списка вместо тебя. Выбирай и пользуйся!" Но проблема в том, что надо разобраться в настройке и воспользоваться десятком пакетов, позаботившись о том, чтоб они совпадали с версией, которая описана в документации и не вступали друг с другом в конфликты… Слишком сложно. Хочется чего-то проще, такого же простого, как в мире Django, из которого я пришел. Какой-то один пакет, после установки которого в store сами по волшебству складываются все нужные данные — бери и пользуйся.

Ну, я и решил — если такого решения нет, напишу-ка я его сам.

Постановка задачи

Убирая всю лирику из первого абзаца, получаю задачу — нам нужно создать инструмент, который будет:

  1. Делать асинхронный GET-запрос к REST API.
  2. Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.
  3. Складывать полученные данные в store и следить за актуальностью хранящихся данных.

По описанию выходит, что состоять пакет будет из action creator'а, middleware и reducer'а.

Читать полностью »

Анонс RamblerFront& #1 - 1

8 июня на Мансарде Rambler&Co состоится первый внешний RamblerFront& meetup, на котором наши сотрудники поделятся прикладными знаниями в области frontend-разработки.
Читать полностью »

«Готовимся к переходу на Angular 4»: Tinkoff.ru о JS-разработке - 1
Как известно, клиенты Tinkoff.ru видят перед собой не отделение банка, а интерфейс сайта или мобильного приложения — так что для компании две эти вещи особенно важны. О мобильной разработке мы её недавно уже расспрашивали. А теперь в преддверии конференции HolyJS, где разработчик Tinkoff.ru Алексей Носов выступит с докладом, задали вопросы о JS/фронтенде: и самому Алексею, и руководителю HR-проектов компании Ольге Шпунтенко.
Читать полностью »

Или Охота на Кракена. В предыдущих заметках (тут и тут) я делился своим Braindump на тему различных архитектурных стилей, в частности Model-View-Controller и Flux.

Я отметил, что не увидел в лице Flux какой-то революции, этот шаблон не что-то новое. Я увидел в нем схожесть с Reenskaug-MVC 1979 года. Также, я упомянул, что решил убрать из своего кода Redux (одна из реализаций Flux). Мне кажется, эти моменты необходимо пояснить более развернуто. Моей целью не было убедить читателя в том, что Flux надо называть MVC, так же я не хотел сказать, что redux-модуль плох и от него нужно полностью отказаться.

Так как же относится тогда к Flux?

Для начала надо определится что же такое Flux. Во-первых это определенно архитектурный стиль, при чем на на данный момент, уже не только для клиентских web-приложений. Во-вторых это набор четко определенных компонентов и терминов.
Читать полностью »

Всем привет! Недавно Дэн Абрамов, создатель Redux, оставил довольно массивный комментарий к статье на Medium Things nobody will tell you about React.js, который очень быстро разошёлся популярностью и довольно скоро набрал раза в 3 больше рекомендаций, чем сама статья :)
Собственно, текущая статья является моим переводом его комментария, так как последняя содержит ценные замечания по поводу актуального и будущего состояния React / React Router.
Надеюсь, кому-то это будет полезным.


Привет, спасибо за обратную связь! :)

Я ценю, что вы поделились своим неприятным опытом работы с React.

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

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

В прошлой статье мы рассказали, как в целом устроен фронтенд программы, обсудили технологический стек. Данную статью посвятим обсуждению Redux  —  почему мы называем его сердцем архитектуры ЕФС.

Redux как сердце архитектуры фронтенда Единой фронтальной системы - 1
Читать полностью »

Twitter Lite и высокопроизводительные прогрессивные веб-приложения на React

Как мы оптимизировали Twitter Lite - 1

Взгляд на то, как удаляли обычные и необычные узкие места в производительности при создании одного из крупнейших в мире прогрессивных веб-приложений (PWA) на React.js — Twitter Lite

Создание быстрого веб-приложения требует многих циклов измерений, куда тратится время. Нужно понять, почему это происходит, и применить потенциальные исправления. К сожалению, не бывает одного простого решения. Производительность — это бесконечная игра, где мы ищем и измеряем области для улучшения. В Twitter Lite сделано много маленьких улучшений в разных сферах: от первоначального времени загрузки до рендеринга компонентов React (и предотвращения повторного рендеринга), загрузки изображений и много другого. Большинство изменений небольшие, но они складываются, и в конечном результате мы получили одно из самых больших и быстрых прогрессивных веб-приложений.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js