Redux: Предложение: переименовать «магазины» в «редукторы».

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

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

Я честно считаю, что сейчас это еще более запутанно. Абсолютно анекдотично, но у меня было несколько человек в реале, которые запутались, думая о том, как «магазин» может быть без гражданства.

Основные характеристики «хранилищ» в традиционном Flux заключаются в том, что они 1) удерживают состояние и 2) генерируют события изменения. Ни то, ни другое не соответствует действительности в Redux.

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

Интересно, есть ли термин, который не звучит как FP, но также не является «магазином».
Домены?

OTOH уже называется Redux, так что, по крайней мере, звучит как «редуктор».

Как насчет «шаговых обновлений» или «степперов», которые перемещают ваше состояние на один шаг вперед. Я видел, как это использовалось в литературе по Elm, имея функцию с именем step , update или next

Домены содержат багаж node.js.

Они не являются хранилищами того, как они функционируют, но вы все равно помещаете туда свою логику состояния, как хранилища потоков. Они государственные менеджеры, как и полагается флюсовым магазинам.

Редукторы подойдут, если вы хотите изменить его название.

Тем более, что "reducer" - точное описание того, что они есть на самом деле :)

Апдейтеры? Звучит описательно + менее пафосно, чем редукторы.

Мне тоже нравится reducer

Думаю, я не понимаю, почему «редуктор» - снобизм. Разве не лучше использовать настоящий термин, чем изобретать новый, менее описательный?

Я предполагаю, что оба могут быть действительными, и это зависит от того, с какой точки зрения вы это видите: _редуктор_ действий (в состояние) или _обновление_ состояния.

«Updater» подразумевает, что это измененный. «Редуктор» дает понять, что вы возвращаете новое состояние, а не изменяете старое.

Я думаю, это сильная сторона в пользу, может помочь с проблемой, связанной с некорректной работой redux с мутациями.

Я действительно ценю необходимость поддерживать Redux дружественным к людям, которые не знакомы с FP, но мы можем решить это с помощью более качественной документации. Мне нравятся текущие документы, но на первый взгляд они немного утомительны. Был бы очень полезен хороший сайт документации, который ставит знакомые вещи (создатели действий, логику редуктора) на передний план, а не более сложные (промежуточное ПО, горячая перезагрузка).

И все же, судя по быстрому росту здесь следующих, должно быть, мы что-то делаем правильно :)

Я готов изменить «Магазины» на «Редукторы», если это произойдет вместе с лучшими документами.

Важным элементом является сохранение атмосферы «это как Flux, но лучше, не волнуйтесь». Я не хочу, чтобы люди думали, что это похоже на Reflux или что-то в этом роде, что звучит как Flux, но нарушает некоторые из его приятных свойств. Я также не хочу, чтобы они думали, что им нужно изучать FP. Пока мы сможем сохранить это, я согласен с этим изменением.

Предложение, в котором я менее уверен: если мы переименуем класс Redux в Store (подумайте об этом: его две цели - удерживать состояние и генерировать события изменения), тогда API верхнего уровня станет:

const store = createStore(reducers);

<Provider store={store} />

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

Мне это нравится, хотя тогда store.dispatch кажется неправильным.

Да, это единственное, что мне не очень нравится, но другие методы имеют смысл: store.getState() , store.setState() , store.subscribe()

Теперь, когда я думаю об этом, мы на самом деле ничего не «отправляем».
Ух, именование - это кроличья нора.

Итак, что у нас есть:

• действие (создатели)
• (магазин) редуктор
• функции промежуточного программного обеспечения
• функции обратного вызова (слушателя)
• что-то, что запускает цепочку вызовов функций (называется диспетчером)
• что-то, что содержит изменяемое состояние (с сеттерами и геттерами)

Может быть, сделать шаг назад и переосмыслить название?

Может быть, store.dispatch не так уж и плохо. Мы можем просто объяснить, что вместо множества магазинов у нас есть один магазин, и вы составляете его из редукторов. Нет магазинов = нет необходимости в отдельном диспетчере, поэтому dispatch доступен прямо в магазине.

@gaearon Согласен.

@emmenko Хорошее резюме. Любая терминологическая разбивка должна различать "создатели действий" и "действия". Следует также различать _dispatcher_ или _dispatch strategy_, которые включают промежуточное ПО + редукторы, а также метод _dispatch_, который запускает _dispatch cycle_.

Давай сделаем это:

• Переименовать магазины в редукторы
• Переименуйте экземпляр Redux в Store в соответствии с https://github.com/gaearon/redux/issues/137#issuecomment -113252359.
• Объясните: если вы прищуриваетесь на традиционные магазины Flux, вы увидите, что в них застряли редукторы.

Кто-нибудь хочет возглавить новую работу с документами? Потребуется некоторая структурированность: глоссарий, README, простое практическое руководство и, возможно, более подробное руководство по «проектным решениям».

@gaearon Я добровольно возглавлю это :) Я уже начал набросок.

Спасибо: +1:

Я добровольно возглавлю это

Спасибо! : +1:: +1:: +1:

Лично мне в конечном итоге хотелось бы иметь автоматически сгенерированный веб-сайт с:

• начиная
• учебные пособия
• живые примеры

... и в качестве полезной функции:

• сгенерированная документация а-ля docco (например: как jasmine ), чтобы исходный код был четко объяснен

Но начать с уценки и jsdoc, конечно же, первый шаг;)

Верно, я думаю, что первым шагом является создание документации в форме Markdown, а затем мы можем перенести их на действительно хороший сайт документации. : +1: для JSDoc тоже. Сегодня вечером я собираюсь нанести последний удар по https://github.com/gaearon/redux/pull/87, но я не уверен, что аннотации Flow того стоят, если мы не избавим кодовую базу от перегрузки функций. (Или если кто-то не научит меня правильно набирать их, не жалуясь на Flow.)

Думаю, Flow не является приоритетным банкоматом.

+1 для магазинов, называемых редукторами.

Я не любил называть эти более декларативные магазины вещей без гражданства.

Мне нравятся идеи новых названий. Я также предлагаю переименовать Connector во что-то вроде Subscription . Connector является очень общим, и хотя я понимаю, что он подключает состояние и диспетчер redux к своим дочерним элементам, я думаю, что подписка - лучшее описание того, что происходит. Немного натянуто, что вместе с подпиской у вас есть диспетчер, но я думаю, что это нормально.

-1 для магазинов, называемых редукторами, поскольку это название не очень интуитивно понятно для новых пользователей (по крайней мере, тех, кто не имеет опыта функционального программирования). Может быть, лучше было бы Updater или Transformer, или Store Updater, если бы мы хотели сказать об этом более подробно.

«Трансформеры» предлагались довольно много раз. Он не предполагает изменчивой природы, такой как Updaters, более доступен, чем Reducers, и не несет в себе коннотации «хранилищ», как у Stores.

Как тебе Трансформеры?

+1 для редукторов

Как отмечает @faassen в Твиттере, хороший аргумент в пользу «редюсеров» - это обратный вызов имени проекта. У нас есть шанс сказать: «Это похоже на Flux, но есть один магазин». Точно так же, как вы можете скомпоновать свое приложение из компонентов React, в Redux вы составляете этот Store из редукторов. Они называются редукторами, потому что их подпись соответствует функции, переданной в [].reduce() : (state, action) => state . Бла-бла-бла »

angular распространяется как лесной пожар и использует такие слова, как

• директива
• изолировать
• включать

Игнорирование программирования, преобразование и сокращение - разные вещи. Я бы выбрал наиболее точное имя.

Если они не хранят данные, не называйте их магазинами.

Вы переходите из одной формы в другую или сокращаете от многих ценностей к одной?

Трансформер => карта
Редуктор => уменьшить

Для меня это похоже на сокращение.

Я тоже за reducers ! : +1:

Вдохновляйтесь Elm. https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

Лучшее слово будет update . Магазин - ерунда, всегда была «Модель». Не нужно изобретать велосипед или путать людей.

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

Вы переходите из одной формы в другую или сокращаете от многих ценностей к одной?

Я накапливаю. «Как действие превращает состояние в следующее состояние». Концептуально они сокращают количество действий из начального (неопределенного) состояния, а мемоизация - это просто оптимизация.

Государственный трансформатор

Старайтесь как можно больше не изобретать / открывать заново. Люди называли это reduce , scan , fold и update .

reducer кажется точным с точки зрения javascript ...
Не вижу смысла давать ему имя из концепции другого языка, даже если это более точно.

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

@vramana это не map , это reduce , поскольку он берет ранее накопленные state и новый action и возвращает новый state .

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

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

Теперь у вас действительно есть stream из actions по времени, что концептуально то же самое, что и массив, но по времени (вы можете уменьшить его до stream из state s).

Мне нравится думать об этом как о проекции (журнала событий на структуру данных).
Люди из БД называли это «материализованными представлениями».

Мне нравится сворачивать или сворачивать, это хорошо понимают разные сообщества

Я предпочитаю Трансформаторы Редукторам: из нормального английского использования этого слова понятно, что это значит.

Редукторы.
Во-первых, это библиотека javascript, а в javascript есть [].reduce(reducer, initialState) .
Во-вторых, Redu (cer) x уже есть в имени библиотеки.
В-третьих, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , другие люди и библиотеки будут использовать термин «редукторы».

Редуктор точен и имеет прецедент в ванильном JS. Не знаю, как это можно улучшить.

Редукторы тогда должны быть.

(Следите за прогрессом в # 140)

Иногда я нахожу старые дискуссии, называя их «магазинами», и удивляюсь, насколько смехотворно запутанным это было в ретроспективе.

"государственный контейнер"?

Да, это было хорошее изменение :)