Комментарии 66
Я не понял. А где редьюсер? Или как его создать?
Что вы понимаете под редьюсером? По факту обычные редьюсеры в явном виде скрыты под капотом. Если вам нужен метод для изменения state, то в статье есть пример:
Это и есть экшн + редюсер. При вызове addTODO('do some stuff') в state добавится этот элемент.
import { createAction } from 'redbox'
export const initialState = {
TODO: []
}
export const addTODO = createAction((state, payload) => {
return {
...state,
TODO: [
...state.TODO,
payload
]
}
})
Это и есть экшн + редюсер. При вызове addTODO('do some stuff') в state добавится этот элемент.
Это конечно хорошо, но я хочу иметь ActionReducer\<T\>, как это получить? (чтобы привязать хранилище в ангуляре)
Ну Вы взяли и в очередной раз скрыли «под капот» то, ради чего redux создавался — явной обработки всех экшенов в редьюсерах. Этот подход скрытия — это начало развития flux, даже библиотека была такая — reflux, которая как раз прятала диспетчер внутрь экшенов.
А что неявного в моем подходе? Я не претендую на звание создателя чего-то нереального. Я делал либу в первую очередь для себя и для использования в реальном проекте и это помогло сократить код в разы. И все работает и команде удобно использовать такой подход. Redbox это не замена Redux это скорее сахар.
Я делал либу в первую очередь для себя и для использования в реальном проекте и это помогло сократить код в разы
Это отлично, но, по-сути, вы сделали
reflux поверх redux, хотя в последнем намеренно избегается такой подход.Неявная тут реакция стейта на экшен, т.к. стейт у вас теперь «как бы упакован» в функцию addTodo, когда по философии redux необходимо явно описать реакцию в редьюсере.
Как вот быть, если нужно в нескольких местах в общем стейте отреагировать на 1 экшен addTodo без изменения непосредственно addTodo?
Напишите, пожалуйста, пример что вы хотите реализовать посредством просто Redux, т.к. я не совсем понял что вы хотите написав «без изменения непосредственно addTodo».
Если же я правильно понял и вы хотите просто изменить основное дерево state в нескольких местах при вызове одного экшна что мешает вам вызвать несколько экшн-редьюсеров? Пример в этом комментарии
Если же я правильно понял и вы хотите просто изменить основное дерево state в нескольких местах при вызове одного экшна что мешает вам вызвать несколько экшн-редьюсеров? Пример в этом комментарии
тут недавно еще это проскакивало https://medium.com/@nate_wang/a-new-approach-for-managing-redux-actions-91c26ce8b5da#.cj2jzhbf7
Ага, уже были попытки изобрести похожий велосипед: https://github.com/erikras/ducks-modular-redux
Это не велосипед, а паттерн организации проекта на Redux. И это совсем другое.
Паттерн, да. Говоря «велосипед», не имел в виду ничего плохого. Идея звучит вполне здраво, хотя в деле я её не пробовал.
Это совсем другое, чем что? Чем RedBox, о котором пишет автор этой статьи на Хабре? Тогда да, конечно. Чем подход, о котором пишет человек на Медиуме по ссылке. Тогда нет, не согласен. Довольно близкие идеи и реализация.
Это совсем другое, чем что? Чем RedBox, о котором пишет автор этой статьи на Хабре? Тогда да, конечно. Чем подход, о котором пишет человек на Медиуме по ссылке. Тогда нет, не согласен. Довольно близкие идеи и реализация.
Ну да, не уточнил. Под «другое» я имел в виду, что это не способ как-то особенно писать код, это не какая-то библиотека сама по себе, просто паттерн. Действительно, близко к тому, о чем говорится по ссылке выше (A New Approach for Managing Redux Actions). Пропустил этот момент, думал сравнивается с либой из топика.
Уже был RedBox в контексте React. Некрасиво названия «красть».
да, хорошо бы переименовать
Эммм, название я не крал, не надо обвинять плз… я название выбираю по свободности в npm https://www.npmjs.com/package/redbox. Как видите оно пренадлежит мне…
Хабр как всегда… лишь бы обосрать, а не написать по делу. Можно придраться еще к тому что я использовал 'red' в начале названия… идиотизм
Хабр как всегда… лишь бы обосрать, а не написать по делу. Можно придраться еще к тому что я использовал 'red' в начале названия… идиотизм
В чем новизна ваших идей? https://github.com/acdlite/redux-actions
Явной новизны самой идеи нет. Естественно такую задачу как упрощение создания редьюсеров в Redux решали и до меня. Ваш пример я посмотрел (поверхностно). В нем все равно есть намек на типы. Нет встроенного решения для экшнов, т.е. это голые редьюсеры, над которыми вам по старинке придется создавать экшены и передавать данные в созданный редьюсер… Мое решение как минимум изящнее. Что касается возможных сложностей с реализацией частных случаев при использовании Redbox, как я и писал в статья, я готов к предложениям и критике… модуль новый, сырой и нуждается в доработках (ессесно).
А я всегда думал, что сначала надо обкатать модуль на нескольких проектах, сложнее TODO List. Стабилизировать и только потом идти в сообщество в поиске фидбека и контрибьютеров.
Модуль используется сейчас в реальном проекте, работает стабильно. Возможно я некорректно выразился в прошлом комментарии: имелось ввиду, что бывают частные случаи, которые (возможно, у меня такого не было) будет сложно решить используя мой модуль.
Я бы для демонстрации модуля сделал бы не большое приложение и выложил бы его исходники. И написал бы об этом пост. Где, как раз, рассказал и показал как оно работает и какие плюсы.
Мне кажется у всех могло бы возникнуть меньше вопросов или более конкретизированные.
Плюс многие из нас код читают лучше чем статьи :)
Мне кажется у всех могло бы возникнуть меньше вопросов или более конкретизированные.
Плюс многие из нас код читают лучше чем статьи :)
Вы правы, спасибо за совет. Постараюсь на днях сделать подробный пример с описанием. Правда как это оформить? Как апдейт к статье?
Пример добавил: https://pavelivanov.github.io/redaction/
Исходники тут: https://github.com/pavelivanov/redaction/tree/master/example
Позже добавлю тесты
Исходники тут: https://github.com/pavelivanov/redaction/tree/master/example
Позже добавлю тесты
обвинение в краже здесь некорректно.
Но все же получается конфуз, когда есть две библиотеки с одинаковым названием, но разным назначением.
В проекте и использованием обоих будет сложновато объяснять какой именно редбокс имелся в виду.
Ну и, справедливости ради, библиотека, показывающая красный квадратик более соотвествует названию, чем утилита для создания экшенов.
Если бы вы зашли на гитхаб, то заметили бы откуда взялось название. Я пользовался либой React Toolbox. Она дает набор комонентов для реакта. Я искал название созвучное с Redux. Есть множество вариаций с начальными буквами «Red». Исходя из этого я решил что Redux Tool Box будет нормально. Потому что модуль дает набор функционала для удобной работы с Redux. Таким образом получилось название REDuxtoolBOX. А что касается красного квадратика… квадратик это Square на английском, если уж на то пошло… А Box — коробка.
А что касается красного квадратика… квадратик это Square на английском, если уж на то пошло… А Box — коробка.
Для справедливости — она и чаще прямоугольничек показывает, чем квадратик, потому пусть называется RedRectangle. Хотя еще более семантически подходит RedBackground. Не парьтесь, все нормально, это что-то ребятам делается сегодня, что они так в это название вцепились.
Спасибо за объяснение этимологии вашего названия, ваша идея стала понятнее.
Какой миленький, прям ностальгия по php первых версий, где ошибки прям пользователю в лицо вываливались. Истинно история по спирали.
так удобно же.
Поправил скрипт, сохранил, увидел. Когда экран маленький и нет места для консоли — самое то.
Разумеется, для продакшена эту фичу нужно отключать.
А красный он чтобы еще неудобнее было? ;) Что, если бы экран белый остался, то программист не догадался бы, что там ошибка?
А место в стектрейсе Вы идете в коде руками искать?
не понимаю вопрос.
А как надо?
Я имел в виду, что стектрейс ошибки в консоли кликабелен и по нему можно перейти к месту выброса в коде, чего не сделаешь из RedBox.
У меня в консоли ничего не кликается (пользуюсь стандартым терминалом MacOs).
Более того, оказывается в rebox можно сделать ссылки кликабельными, но я этим никогда не пользовался
Подождите, мне казалось, что весь прикол как раз в том, чтобы отделять экшны от редьюсеров, разве нет? Иначе вместо модели событий и обработчиков мы возвращаемся к модели вызова функций (название функции — тип экшна, параметры — его payload, тело функции — сам редьюсер). Другими словами, как в RedBox реализовать редьюсер, который обрабатывает несколько экшнов, и, наоборот, несколько редьюсеров, реагирующих на один и тот же экшн?
А к вопросу стрёмных текстовых констант вот — https://github.com/pauldijou/redux-act
А к вопросу стрёмных текстовых констант вот — https://github.com/pauldijou/redux-act
Это хорошее замечание. Вы отчасти правы. Но. Что вам мешает создать редьюсер и использовать его в нескольких экшнах? Или создать экшн и в его onResponse вызывать несколько редьюсеров?
В целом я не ушел далеко от стандартов, просто упаковал их в сахар.
В целом я не ушел далеко от стандартов, просто упаковал их в сахар.
Не до конца понимаю, что вы предлагаете. Можете пример кода на RedBox набросать для обоих случаев? Только для синхронных экшнов, без request, пожалуйста.
import actions from 'core/actions'
export const doMultipleActions = createAction((state, { foo, bar }) => {
actions.reducersFolderName.setFoo(foo)
actions.reducersFolderName.setBar(bar)
})
export const initialState = {
foo: null,
bar: null
}
export const setFoo = createAction((state, payload) => ({ ...state, foo: payload }))
export const setBar = createAction((state, payload) => ({ ...state, bar: payload }))
doMultipleActions({
foo: 1,
bar: 2
})
Это, конечно, выглядит не совсем корректно с точки зрения использования редьюсера, но работать будет как часы.
мимо.
По-моему тут возникает проблема зависимостей.
Давайте представим, что у нас есть несколько компонент: один предоставляет юзеру возможность логиниться, второй показывает прогрессбар, третий отображает ошибки. И чтобы они никак не были связаны между собой — каждый следит только за своим кусочком стейта. То есть предполагается, что ошибки и процессы могут быть из кучи других мест.
И вот юзер вводит логин-пароль, вызываем экшен API_REQUEST, который шлет запрос через какую-нибудь миддлварь —> компонент процесса показывает прогрессбар —> приходит ответ сервера с ошибкой авторизации —> Прогрессбар пропадает —> ошибка висит в углу пока ее не скроют или она не перестанет быть актуальной —> у формочки логина тоже отображается ошибка.
Если у нас отделены редюсеры от экшенов, то это легко реализовать, подписав каждый редюсер на нужные нам экшены: редюсер юзера (из стейта которого берет данные об ошибках формочка) ждет юзердату / ошибку в API_RESPONSE, прогрессбар положил в стейт данные на API_REQUEST и убрал их на API_RESPONSE, а редюсер ошибок положил ошибку, получив ее в API_RESPONSE.
Итого у нас три несвязанных компонента со своими стейтами и своей логикой, которые фактически слушают одни и те же события: два экшена.
В вашем же случае, как я понимаю, придется создать для каждого компонента отдельные экшено-редюсеры и явно комбинировать их в «мега экшене» (типа doMultipleActions). И мне почему-то кажется что в редкс-девтулз мы увидим, как задиспатчился этот самый «мега экшен», а тот в свою очередь задиспатчил еще несколько. Т.е. мы получаем более сложную хистори, которую в случае чего будет сложнее откатывать (если речь пойдет не про логин, а скажем про редактирование чего-нибудь с возможностью у юзера сделать анду).
Надеюсь я понятно изложил пример. Если я не прав, то поправьте меня. Спасибо.
Давайте представим, что у нас есть несколько компонент: один предоставляет юзеру возможность логиниться, второй показывает прогрессбар, третий отображает ошибки. И чтобы они никак не были связаны между собой — каждый следит только за своим кусочком стейта. То есть предполагается, что ошибки и процессы могут быть из кучи других мест.
И вот юзер вводит логин-пароль, вызываем экшен API_REQUEST, который шлет запрос через какую-нибудь миддлварь —> компонент процесса показывает прогрессбар —> приходит ответ сервера с ошибкой авторизации —> Прогрессбар пропадает —> ошибка висит в углу пока ее не скроют или она не перестанет быть актуальной —> у формочки логина тоже отображается ошибка.
Если у нас отделены редюсеры от экшенов, то это легко реализовать, подписав каждый редюсер на нужные нам экшены: редюсер юзера (из стейта которого берет данные об ошибках формочка) ждет юзердату / ошибку в API_RESPONSE, прогрессбар положил в стейт данные на API_REQUEST и убрал их на API_RESPONSE, а редюсер ошибок положил ошибку, получив ее в API_RESPONSE.
Итого у нас три несвязанных компонента со своими стейтами и своей логикой, которые фактически слушают одни и те же события: два экшена.
В вашем же случае, как я понимаю, придется создать для каждого компонента отдельные экшено-редюсеры и явно комбинировать их в «мега экшене» (типа doMultipleActions). И мне почему-то кажется что в редкс-девтулз мы увидим, как задиспатчился этот самый «мега экшен», а тот в свою очередь задиспатчил еще несколько. Т.е. мы получаем более сложную хистори, которую в случае чего будет сложнее откатывать (если речь пойдет не про логин, а скажем про редактирование чего-нибудь с возможностью у юзера сделать анду).
Надеюсь я понятно изложил пример. Если я не прав, то поправьте меня. Спасибо.
А вы можете привести пример кода, пожалуйста. Минимальный чтобы понять как вы хотите построить структуру и я докажу (почти уверен) что в структуре на redbox будет меньше кода, и лишнего не будет и вызываться будут те же диспатчи (за исключением состояний запроса)
На самом деле этот пример — упрощенный кейс из моей практики в текущем проекте, и он касался не логина. Но, если это поможет, то оформлю его в виде кода, максимально упростив (без проверок, иммутабельных состояний и прочих вещей, которые должны присутствовать) и, чтобы не углубляться в реализацию асинхронных запросов, заменю запрос экшеном с использованием redux-thunk, который делает диспатч FSA и второй диспатч по таймауту.
// actions
export const login = (username, password) => (dispatch) => {
dispatch({
type: 'API_REQUEST',
payload: {
uri: '/login',
body: { username, password },
},
});
setTimeout(
() => dispatch({
type: 'API_RESPONSE',
payload: {
uri: '/login',
response: 401,
},
error: true,
}
), 5000);
};
// users/reducer
export default (userState = {}, action) => {
if (
action.payload.uri === '/login' &&
action.type === 'API_RESPONSE'
) {
if (action.error) {
return {
error: 401,
};
}
userState = action.payload.response;
}
return userState;
};
// progress/reducer
export default (progressState = [], action) => {
if (action.type === 'API_REQUEST') {
progressState.push(action.payload.uri);
}
if (action.type === 'API_RESPONSE') {
const i = progressState.indexOf(action.payload.uri);
progressState.splice(i, 1);
}
return progressState;
};
// errors/reducer
import { ERROR_MESSAGES } from './messages';
export default (errorsState = [], action) => {
if (action.type === 'API_RESPONSE' && action.error) {
errorsState.push({
requestUri: action.payload.uri,
message: ERROR_MESSAGES[action.payload.response],
});
}
return errorsState;
};
// rootReducer
import users from '/users/reducer';
import progress from '/progress/reducer';
import errors from '/errors/reducer';
export default combineReducers({
users,
progress,
errors,
});
И конечно же тут на самом деле будут константы вместо магических экшн-тайпов и урлов :)
А компоненты, соответственно получают эти кусочки стейтов (с помощью селекторов / курсоров выдергивают только свои) и:
А компоненты, соответственно получают эти кусочки стейтов (с помощью селекторов / курсоров выдергивают только свои) и:
- формочка показывает ошибки, если они есть или закрывается если есть юзердата
- прогрессбар в данном случае просто крутилка, которая отображается пока длина массива больше 0
- ошибки показываются, если есть что показать (в данном примере без удаления и проверок на актуальность)
Пример ваш понял, вот набросал:
Если вы имеете ввиду что в моем случае нельзя при создании экшна построить сразу цепочку вызовов, то это относится к архитектуре и, имхо, я буду больше рад такому варианту с цепочкой асинхронных запросов нежели буду довольствоваться лапше из кода =/ К сожалению, практика показала что такой вариант в разы лучше. Есть огромный проект, в котором используется чистый Redux (примерно 400 апи запросов) и есть еще больше проект где используется подход Redbox и кода в разы меньше / чище и поддерживать в разы легче.
// actions/user.js
export const login = createAction({
endpoint: '/login',
method: 'POST'
})
// containers/Login/index.js
@connect((state) => ({
authentication: state.user.authentication
}))
export default class Login extends React.Component {
auth = () => {
actions.auth.login({
subset: 'authentication',
body: {
username,
password
},
onResponse: ({ body }) => {
// запускаем любой другой асинхронный вызов, если нужно
}
})
}
render() {
const { authentication } = this.props
if (authentication.pending) {
return (
<Loader />
)
}
if (authentication.error) {
return (
<div>Authentication ERROR</div>
)
}
return (
<div>
<AuthForm onSubmit={this.auth} />
</div>
)
}
}
Если вы имеете ввиду что в моем случае нельзя при создании экшна построить сразу цепочку вызовов, то это относится к архитектуре и, имхо, я буду больше рад такому варианту с цепочкой асинхронных запросов нежели буду довольствоваться лапше из кода =/ К сожалению, практика показала что такой вариант в разы лучше. Есть огромный проект, в котором используется чистый Redux (примерно 400 апи запросов) и есть еще больше проект где используется подход Redbox и кода в разы меньше / чище и поддерживать в разы легче.
Забыл описание добавить к коду: (возможно не оч корректный пример был) т.к. внутри есть 3 состояния, то и через коннект в компонент попадают эти состояния, которые можно использовать pending — рисуем лоадер, error — рисуем ошибку, data есть — рисуем ее. И не нужно городить однотипную логику каждый раз… ну или изобретать все-таки свой велосипед прийдется чтобы не плодить код внутри файлов =/
Это я понял.
Но в вашем примере получается, что все эти три компонента — прогрессбар, ошибка и данные юзера связаны между собой (смотрят в один кусок стейта). То есть их независимость, о которой я говорил, теряется.
В моем же примере ошибки могут приходить из любых других асинхронных запросов или даже вполне себе синхронных, например, форма не прошла валидацию, аналогично и с прогрессбаром.
п.с.
Минусы не мои :)
Но в вашем примере получается, что все эти три компонента — прогрессбар, ошибка и данные юзера связаны между собой (смотрят в один кусок стейта). То есть их независимость, о которой я говорил, теряется.
В моем же примере ошибки могут приходить из любых других асинхронных запросов или даже вполне себе синхронных, например, форма не прошла валидацию, аналогично и с прогрессбаром.
п.с.
Минусы не мои :)
Т.е. вы внутри одного файла экшнов хотите вызывать редьюсеры из разных файлов?
п.с.
К минусам необоснованным на хабре я привык… пофигу)
п.с.
К минусам необоснованным на хабре я привык… пофигу)
При использовании Redux вы создаете отдельно экшны и отдельно редьюсеры, они между собой никак не связаны, в экшнах вы вызываете диспатч и передаете тип вызываемого редьюсера. Чтобы вызвать 3 редьюсера придется сделать 3 диспатча.
Что мешает тогда сделать так:
Код ведь чище и его меньше, читать удобнее и поддерживать. Все понятно, откуда что берется.
Я к тому что суть не меняется… это все теже редьюсеры… Просто теперь не нужны типы и диспатч метод. Внутри redbox, если вы посмотрите, создаются все теже комбинированные редьюсеры, просто типы для них создаются уникальные от имени файла, в котором были созданы и имени метода, которым вы его обозвали. А диспатч передается один раз в процессе инициализации и делается замыкание
Что мешает тогда сделать так:
// actions/index.js
import actions from './redbox-actions'
export const someAction = () => {
actions.user.authStart()
request()
.then((result) => {
actions.user.authSuccess(result)
actions.user.authComplete()
})
.catch((err) => {
actions.user.authError(err)
actions.user.authComplete()
})
//...
}
export default actions
Код ведь чище и его меньше, читать удобнее и поддерживать. Все понятно, откуда что берется.
Я к тому что суть не меняется… это все теже редьюсеры… Просто теперь не нужны типы и диспатч метод. Внутри redbox, если вы посмотрите, создаются все теже комбинированные редьюсеры, просто типы для них создаются уникальные от имени файла, в котором были созданы и имени метода, которым вы его обозвали. А диспатч передается один раз в процессе инициализации и делается замыкание
… и передаете тип вызываемого редьюсера. Чтобы вызвать 3 редьюсера придется сделать 3 диспатча.
Это утверждение не верно. В Redux есть экшены, которые изначально являются простыми объектами с определенной структурой (Flux Standart Actions), который содержит в том числе тип экшена. Тип же это любая строка, циферка или что угодно, с чем мы сможем потом сравнить (а чтобы избежать ошибок — их выносят в отдельный файлик констант). И есть редюсеры, которые комбинируются с помощью combineReducers. То есть фактически редюсер всегд один, но может состоять из подмножества небольших редюсеров.
Что происходит во время диспатча — экшен прокидывается в этот самый единственный редюсер, а тот в свою очередь прокидывает экшен внутрь всех дочерних, каждый вовзвращает свой кусочек стейта и в итоге мы получаем новый стейт.
То есть, если не связывать тайпы с редюсерами, а чтобы тайп был фактом действия (как это рекомендует сам Дэн Абрамов), то получится что экшентайпы будут выглядеть, например, так:
COUNTER_TICK
API_REQUEST
MESSAGE_SENDED
MESSAGE_READED
и т.д.
При этом любой редюсер может реагировать на любой из экшенов. В примерах Redux-а это делается с помощью switch(action.type) {… } внутри любого из них.
Все, я вас, кажется, понял… вы хотите один и тотже ЭКШНТИП назначать в switch case разных редьюсеров?
То есть, если не связывать тайпы с редюсерами, а чтобы тайп был фактом действия (как это рекомендует сам Дэн Абрамов), то получится что экшентайпы будут выглядеть, например, так:
COUNTER_TICK
API_REQUEST
MESSAGE_SENDED
MESSAGE_READED
и т.д.
Я вот не понимаю, зачем придумывать новые страшные названия для самых обычных «событий»? Ну кроме желания показать, что ты модный и молодежный? Может если бы не придумывали свои названия для старых вещей, то люди легче понимали б вас. Вот придумали "Presenter-Component" как синоним связке «View-Controller». Зачем? При этом все, что написано на редакс — тонкая Model. Но нет. «Мы не используем грязный MVC, как эти задроты».
Если копнуть поглубже в концепции и особенности реакта с редуксом, то вы заметите, что там есть некоторые особенности. И, как мне кажется, чтобы в головах разработчиков не возникало лишней путаницы и были данны различные наименования.
Например:
Действия (аналог событий) — главное отличие от привычных нам событий, что на них нельзя подписываться для изменений данных в стейте (модели), их можно только вызывать. Но есть всякие штуки типа redux-saga, которые позволяют создавать подписки для получения неких сайд-эффектов, но это другая песня и делать это нужно осторожно.
Редюсеры (аналог моделей) — все модельки упаковываются в один стор. Главная особенность, что никто напрямую не дергает модельку, а каждая моделька сама применяет к себе действия (события) и, возможно, в следствии меняется. И стор всегда возвращает консистетное состояние всей системы (всех моделей).
Контейнеры (statefull components) (аналог контроллеров) не должен выполнять какой-то логики обработки данных, он должен ее лишь получать и назначать вьюхе (все как в правильном активном MVC). И привязывать вызов экшенов (! но не решать какую модельку когда потрогать и как). И каждый такой контейнер может работать сразу с множеством «моделей» (получать любые данные из стора), хотя привычные всем контроллеры чаще всего работают с одной моделькой. А в связке с редуксом и вовсе многие рекомендуют делать их тоже стейтлесс и все стейты хранить в общем стейте — это снимает множество боли.
Компоненты — да, привычные всем тупые вьюхи.
Отсюда следует вывод, что называть это MVC не верно, т.к. оно имеет ряд концептуальных отличий и одно из самых жирных — отсутствие pub/sub. (с тем же успехом можно MVP и MVVM называть MVC)
Не подумайте что я ярый фанат реакта, но из всех ангуляров и бекбонов он мне доставляет меньше всего боли при разработке сложных приложений (вспоминается цитата из выступления Александра Соловьева про FRP и кложуру «У меня уже все болит от этих чик-чик»). Но я все чаще смотрю в сторону FRP библиотек и языков.
Например:
Действия (аналог событий) — главное отличие от привычных нам событий, что на них нельзя подписываться для изменений данных в стейте (модели), их можно только вызывать. Но есть всякие штуки типа redux-saga, которые позволяют создавать подписки для получения неких сайд-эффектов, но это другая песня и делать это нужно осторожно.
Редюсеры (аналог моделей) — все модельки упаковываются в один стор. Главная особенность, что никто напрямую не дергает модельку, а каждая моделька сама применяет к себе действия (события) и, возможно, в следствии меняется. И стор всегда возвращает консистетное состояние всей системы (всех моделей).
Контейнеры (statefull components) (аналог контроллеров) не должен выполнять какой-то логики обработки данных, он должен ее лишь получать и назначать вьюхе (все как в правильном активном MVC). И привязывать вызов экшенов (! но не решать какую модельку когда потрогать и как). И каждый такой контейнер может работать сразу с множеством «моделей» (получать любые данные из стора), хотя привычные всем контроллеры чаще всего работают с одной моделькой. А в связке с редуксом и вовсе многие рекомендуют делать их тоже стейтлесс и все стейты хранить в общем стейте — это снимает множество боли.
Компоненты — да, привычные всем тупые вьюхи.
Отсюда следует вывод, что называть это MVC не верно, т.к. оно имеет ряд концептуальных отличий и одно из самых жирных — отсутствие pub/sub. (с тем же успехом можно MVP и MVVM называть MVC)
Не подумайте что я ярый фанат реакта, но из всех ангуляров и бекбонов он мне доставляет меньше всего боли при разработке сложных приложений (вспоминается цитата из выступления Александра Соловьева про FRP и кложуру «У меня уже все болит от этих чик-чик»). Но я все чаще смотрю в сторону FRP библиотек и языков.
Это не «новые страшные названия», а старые добрые команды: http://stackoverflow.com/a/4964228/1961479
К сожалению исправить уже не могу… написал чушь… что мешает сделать doMultipleActions обычным методом через экспорт и вызывать несколько экшнов / редьюсеров сразу? Тоже самое и с асинхроннщиной…
Что-то я в простых событиях не вызываю диспатч, только в асинхронных. Код ниже прекрасно работает
export const testAction = () => ({
type: TEST_ACTION
});
Нельзя такие изображения постить в общественном пространстве. Что за маньячество? Куда смотрит администрация?
А где тесты?
Все же чистый redux, без всего этого сокрытия подкапотного и redux-saga для кошерной обработки сайд-эффектов выглядит интереснее.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Redux Action Creators. Без констант и головной боли