оке -_-

Коллеги, от куда лучше делать переход на новую страницу, типа history.push(). Т.е. в компоненте при нажатии на кнопку я делаю dispatch(action). Посылается запрос на сервер, если все ок, то нужно перейти на другую стр., а если ошибка, то возле кнопки появляется сообщение об ошибке. В какой части кода по феншую в этом случае сделать history.push?

Парни, подскажите, как в реакте по клинку на кнопке занести данные в буфер обмена ?

Нужно именно по клику onCopy тут не походит как я понимаю

https://github.com/zenorocha/clipboard.js/

Коллеги, от куда лучше делать переход на новую страницу, типа history.push(). Т.е. в компоненте при нажатии на кнопку я делаю dispatch(action). Посылается запрос на сервер, если все ок, то нужно перейти на другую стр., а если ошибка, то возле кнопки появляется сообщение об ошибке. В какой части кода по феншую в этом случае сделать history.push?

можно в action creator. делаешь что-то что отсылает запрос, потом если поймал ошибку, то диспатчишь что тебе нужно чтобы сообщение отобразить. если все ок то диспатчишь переход

@iamstarkov спасибо, а есть возможность без стороних библиотек это сделать ? во всем проекте нужно 1 строку скопировать, не хотелось бы засорять

@iamstarkov спасибо, а есть возможность без стороних библиотек это сделать ? во всем проекте нужно 1 строку скопировать, не хотелось бы засорять

посмотри исходники, для evergreen браузеров должно быть стандартное апи

ну и его наверное на мдн можно найти

Спасибо, сейчас гляну )

можно в action creator. делаешь что-то что отсылает запрос, потом если поймал ошибку, то диспатчишь что тебе нужно чтобы сообщение отобразить. если все ок то диспатчишь переход

но мне в action creator нужно тогда ссыль на history. Его передать как параметр action creater?

@iamstarkov спасибо, а есть возможность без стороних библиотек это сделать ? во всем проекте нужно 1 строку скопировать, не хотелось бы засорять

Есть API, но не кроссбраузерное

но мне в action creator нужно тогда ссыль на history. Его передать как параметр action creater?

я использую push из редакс роутера

а как этот push получить в action creator?

import { push } from 'react-router-redux'

dispatch(push(something))

но это если ты его используешь

ну, этот роутер

есть мнение что пихать урл в стейт тот еще маразм

кстати, пока отсылал, опять же проблема точки с запятой

вот серьезно, ну нахуя вы отказываетесь если забываете

а зачем делать dispatch(push(something)), почему не push(something)? разве push возвращает объект экшена?

https://github.com/reactjs/react-router-redux/blob/master/src/actions.js

есть мнение что пихать урл в стейт тот еще маразм

о каком ты стейте говоришь

о каком ты стейте говоришь

редукс стейте

редукс стейте

а кто его туда пихает

а кто его туда пихает

> react-router-redux

https://github.com/reactjs/react-router-redux/blob/master/src/actions.js

т.е. мне в редьюссерах нужно следить за этим '@@router/CALL_HISTORY_METHOD' экшеном?

т.е. мне в редьюссерах нужно следить за этим '@@router/CALL_HISTORY_METHOD' экшеном?

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

а, сек. посмотрю

Народ а что вы думаете по поводу того что redux пропагандирует какой-то "view driven design"? - когда мы начинаем разрабатывать исходя из того как данные отображаются на экране или должны отобразится после какого-то действия - получаем кучу всяких акшинов BUTTON_CLICKED , export const CHANGE_ACTIVE_USER_ID = 'CHANGE_ACTIVE_USER_ID'; export const CHANGE_CURRENT_TIME = 'CHANGE_CURRENT_TIME'; export const CHANGE_IS_MOBILE = 'CHANGE_IS_MOBILE'; export const CHANGE_MODAL = 'CHANGE_MODAL'; export const CHANGE_PATH = 'CHANGE_PATH'; export const CHANGE_PLAYING_SONG = 'CHANGE_PLAYING_SONG'; export const CHANGE_SELECTED_PLAYLISTS = 'CHANGE_SELECTED_PLAYLISTS'; export const CHANGE_WIDTH_AND_HEIGHT = 'CHANGE_WIDTH_AND_HEIGHT';и в редюсерах мы обрабатываем все это как потребности наших вьюх.Для маленьких приложений такой подход прекрасно работает но при попытке разработать что-то сложное получается месиво из акшинов TASK_ADDED, TASK_DELETED, TASK_COMPLETED, TASK_RECIEVED на каждый тип сущности когда совершенно логически и естественно хочется выделить все эти акшины в три вида ADD,UPDATE, DELETE и думать в контексте сущностей а не событий. А есть кажется другой подход который кажется называется domain driven design ("DDD"), - который говорит что всю бизнес-логику мы должны сначала разрабатывать в чистом вакууме моделируя сущности как объекты и связи между ними и обрабатывать все изменения состояния в этих моделях через изменения самих объектов (ADD, UPDATE, DELETE). И только потом уже спускаться к отображению на компонентах и вьюхах, будь то мобилки или обычные сайты. То есть бизнес-сущностей может быть совсем немного - юзер, борд, пост, картика, комментарий а вот разнообразного количества того как это все должно отображаться, обновляться в компонентах вот это уже может быть бесконечное количество, но главное что сущности и бизнес-логика сущностей и связей (one-to-many, many-to-many) и совершенно не меняется, меняется только различная привязка и обработка этих данных только по требованию самих компонентов Я думаю второй подход лучше маштабируется при разработке сложных приложений

Ну ты забываешь что Redux это только View, бизнес-логику туда тянуть не надо

даже не знаю что лучше, вопрос или ответ

Народ а что вы думаете по поводу того что redux пропагандирует какой-то "view driven design"? - когда мы начинаем разрабатывать исходя из того как данные отображаются на экране или должны отобразится после какого-то действия - получаем кучу всяких акшинов BUTTON_CLICKED , export const CHANGE_ACTIVE_USER_ID = 'CHANGE_ACTIVE_USER_ID'; export const CHANGE_CURRENT_TIME = 'CHANGE_CURRENT_TIME'; export const CHANGE_IS_MOBILE = 'CHANGE_IS_MOBILE'; export const CHANGE_MODAL = 'CHANGE_MODAL'; export const CHANGE_PATH = 'CHANGE_PATH'; export const CHANGE_PLAYING_SONG = 'CHANGE_PLAYING_SONG'; export const CHANGE_SELECTED_PLAYLISTS = 'CHANGE_SELECTED_PLAYLISTS'; export const CHANGE_WIDTH_AND_HEIGHT = 'CHANGE_WIDTH_AND_HEIGHT';и в редюсерах мы обрабатываем все это как потребности наших вьюх.Для маленьких приложений такой подход прекрасно работает но при попытке разработать что-то сложное получается месиво из акшинов TASK_ADDED, TASK_DELETED, TASK_COMPLETED, TASK_RECIEVED на каждый тип сущности когда совершенно логически и естественно хочется выделить все эти акшины в три вида ADD,UPDATE, DELETE и думать в контексте сущностей а не событий. А есть кажется другой подход который кажется называется domain driven design ("DDD"), - который говорит что всю бизнес-логику мы должны сначала разрабатывать в чистом вакууме моделируя сущности как объекты и связи между ними и обрабатывать все изменения состояния в этих моделях через изменения самих объектов (ADD, UPDATE, DELETE). И только потом уже спускаться к отображению на компонентах и вьюхах, будь то мобилки или обычные сайты. То есть бизнес-сущностей может быть совсем немного - юзер, борд, пост, картика, комментарий а вот разнообразного количества того как это все должно отображаться, обновляться в компонентах вот это уже может быть бесконечное количество, но главное что сущности и бизнес-логика сущностей и связей (one-to-many, many-to-many) и совершенно не меняется, меняется только различная привязка и обработка этих данных только по требованию самих компонентов Я думаю второй подход лучше маштабируется при разработке сложных приложений

> Народ а что вы думаете по поводу того что redux пропагандирует какой-то "view driven design"? react+redux это как раз про state+view

как ты верхние уровни абстракции организуешь зависит от тебя, а не от редакса

redux только view O.o

стоит обратить внимание что реакт и редакс вполне себе отлично существуют друг без друга

идея и тулзы, которые дает редакс очень подходят к ddd. Вы проводите анализ того, что у вас в системе вообще происходит(event storming) и как оно все связано. Т.е. редьюсеры производят только то, что надо вьюхе это правда, они read-model

но сам cqrs вполне норм позволяет делать ddd

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

Просто проблема в том что с редаксом я не могу хранить состояние в виде объектов и связей между ними и моделировать бизнес-логику согласно DDD class User { id; posts = []; comments = []; constructor(data){Object.assign(this, data)} } class Post { id; comments = []; user; constructor(data){Object.assign(this, data)} } class Comment { id; user; constructor(data){Object.assign(this, data)} } var user = new User({id: 'user1', posts: [], comments: []}) var post = new Post({id: 'post1', user: user, comments: []}) user.posts.push(post); var comment = new Comment({id: 'comment1', post: post, user: user}) post.coments.push(comment) user.comments.push(comment)и потом где-то в редюсере state = {user: user} потому что получаются циклические ссылки из-за чего требование вернуть новый иммутабельный объект состояния в редаксе выльется в генерацию новых объектов всего состояния

Так может не использовать его для того, для чего он не предназначен?

не надо так делать, нужно много думать и читать, пока не надо ничего писать

А в чем проблема использовать Immutable.Record?

не надо так делать, нужно много думать и читать, пока не надо ничего писать

Твой подход называется read&think-driven-development))

Просто проблема в том что с редаксом я не могу хранить состояние в виде объектов и связей между ними и моделировать бизнес-логику согласно DDD class User { id; posts = []; comments = []; constructor(data){Object.assign(this, data)} } class Post { id; comments = []; user; constructor(data){Object.assign(this, data)} } class Comment { id; user; constructor(data){Object.assign(this, data)} } var user = new User({id: 'user1', posts: [], comments: []}) var post = new Post({id: 'post1', user: user, comments: []}) user.posts.push(post); var comment = new Comment({id: 'comment1', post: post, user: user}) post.coments.push(comment) user.comments.push(comment)и потом где-то в редюсере state = {user: user} потому что получаются циклические ссылки из-за чего требование вернуть новый иммутабельный объект состояния в редаксе выльется в генерацию новых объектов всего состояния

read-model не имеют связей

все твои связи во write-model

как ты ее организуешь redux не регламентирует(как хочешь)

при этом скорее всего на клиенте тебе как таковая write-model не понадобится. Имею ввиду как принято делать в java/c#/php persist-ignor entity, которые вотчаться через UoW и собираются в единую транзакцию. Такое на клиенте не делается в силу отсутствия транзакций и смысла

А в чем проблема использовать Immutable.Record?

Immutable.Record не позволяет делать циклические ссылки

при этом скорее всего на клиенте тебе как таковая write-model не понадобится. Имею ввиду как принято делать в java/c#/php persist-ignor entity, которые вотчаться через UoW и собираются в единую транзакцию. Такое на клиенте не делается в силу отсутствия транзакций и смысла

Я немного не понимаю что такое write-model. У меня в обработчике (допустим нажатие горячих клавиш) надо перетащить текущий таск вверх или вниз. Для этого мне нужно найти следующий или предыдущий таск чтобы узнать позицию. С объектами и ссылками друг на друга я могу просто написать var node = node.parent.children.filter(node=>...)[0]с редаксом мне нужно постоянно вытаскивать эти объекты из центрального состояния по айдишникам var node = dispatch(getNodeById(node.parentId)).children.map(childId=>dispatch(getNodeById(childId)).filter(node=>...) [0]

что захламляет логику

state - read-model

его надо формировать так, чтобы можно было удобнее всего выводить, считай что эот ваши dto для отображения, готовые

не понял, вы диспатчите какие-то гетеры?

ну, а react-redux с connect чем не подошел?

ну, а react-redux с connect чем не подошел?

в mapStateToProps я вытаскиваю только то что нужно для отображения. А обработчикам событий требуются больше информации. Если выписывать все необходимое в mapStateToProps то будет постоянный перендер на каждое обновления. Для того чтобы получить в обработчике какие-то объекты по айдишнику приходится диспатчить thunk который получает доступ к состоянию - dispatch((_, getState)=>getState().tables.tasks[taskId])

ну у вас read-model плохой

почему ему нужно что-то, чего ему не дает view

Immutable.Record не позволяет делать циклические ссылки

Если очень хочется то можно, правда это мало чем будет напоминать redux, есть же redux-orm, но мне кажется что ты решаешь не ту задачу или не тем путем)

ну, это не железное правило, иногда так действительно может быть проще, мол докинуть еще параметр

Почитай про cqrs

С cqrs мы и получаем такой разброс событий - CHANGE_ACTIVE_USER_ID CHANGE_CURRENT_TIME CHANGE_IS_MOBILE CHANGE_MODAL CHANGE_PATH CHANGE_PLAYING_SONG CHANGE_SELECTED_PLAYLISTS CHANGE_WIDTH_AND_HEIGHT и на каждой тип свой action-creator и свой редюсер. Получаем кучу болерплейта для обычного crud-а. А если бы моделировали логику через сущности то из всех этих событий можно выделить что-то общее CHANGE_ACTIVE_USER_ID это обновление поля у сущности user, CHANGE_CURRENT_TIME это обновление другой сущности и т.д. И можно написать всего один редюсер который будет принимать всего три типа ADD, UPDATE, DELETE, а в параметрах тип сущности и айдишник и что обновить или создать, таким образом избавимся от кучи болеплейта

multireducer

обертки

и тд

вот что-что, но в редаксе бойлерплейт наплодить надо постараться

по ангулару есть такой чатик?

по ангулару есть такой чатик?

https://telegram.me/angular2

С cqrs мы и получаем такой разброс событий - CHANGE_ACTIVE_USER_ID CHANGE_CURRENT_TIME CHANGE_IS_MOBILE CHANGE_MODAL CHANGE_PATH CHANGE_PLAYING_SONG CHANGE_SELECTED_PLAYLISTS CHANGE_WIDTH_AND_HEIGHT и на каждой тип свой action-creator и свой редюсер. Получаем кучу болерплейта для обычного crud-а. А если бы моделировали логику через сущности то из всех этих событий можно выделить что-то общее CHANGE_ACTIVE_USER_ID это обновление поля у сущности user, CHANGE_CURRENT_TIME это обновление другой сущности и т.д. И можно написать всего один редюсер который будет принимать всего три типа ADD, UPDATE, DELETE, а в параметрах тип сущности и айдишник и что обновить или создать, таким образом избавимся от кучи болеплейта

ну так называйте их правильнее, PLAY_SONG, SELECT_PLAYLIST. Ну и если вы crud хотите, а не ddd, то да, делайте общий редьюсер, creator и не парьтесь

доброго вечера! вебпак собирает путь вида "/folder/file" мне нужно "./folder/file"

доброго вечера! вебпак собирает путь вида "/folder/file" мне нужно "./folder/file"

Привет. Нихера не понятно, если честно. Где собирает? Куда собирает?

prod build делает сжатое все

и вот

в index.html

все пути к css и js лежат абсолютно

Привет всем. Пытаю редакс. Помогите разобраться в проблеме одинакого стейта между экшионами.

Есть компонента у которой есть инпат:

<input type="text" name="first-name" placeholder="Введите имя проекта здесь." value={this.props.newProjectName} onChange={this.newProjectNameChange} />

На изменение которого повесил обработчик который диспатчит новой состояние в стор:

newProjectNameChange = (e) => { e.preventDefault(); store.dispatch(newProjectNameChanged(e.target.value)); }

Вот так выглядит функция формирующая экшен:

export function newProjectNameChanged(data) { return { type: NEW_PROJECT_NAME_CHANGED, data: data } }

Вот код редьюсера:

import actions from './actions'; const reducer = (state, action) => { switch (action.type) { case actions.ADD_NEW_PROJECT: return { ...state, projects: projects.push(action.data) } case actions.CHANGE_PROJECT: return { ...state, currentProject: action.data } case actions.NEW_PROJECT_NAME_CHANGED: console.log(action); return { ...state, newProjectName: action.data } case actions.NEW_PROJECT_DESCRIPTION_CHANGED: return { ...state, newProjectDescription: action.data } default: return state } } export default reducer

ну и естественно все это засылаю в стор:

import { createStore, combineReducers } from 'redux'; import { Router, Route, browserHistory } from 'react-router'; import { syncHistoryWithStore, routerReducer } from 'react-router-redux'; import reducers from './reducers'; const store = createStore( combineReducers({ ...reducers, routing: routerReducer }), window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__() ) const history = syncHistoryWithStore(browserHistory, store) export default store;

====

Ввожу какие-нибудь значения в поле на котором висит обработчик - в redux-dev-tools видно что экшен кидается - но если смотреть diff между предыдущим стэйтом и текущим - нету разницы. То есть я в редюсерах вместо копирования и изменения копии стэйта изменяю сам стейт? Нарушается его "иммутабельность" и диффа в итоге нет? Или я снаркоманился и вообще не в этом причина? Оператор расширения использовал так как это показывают в примерах

Просто проблема в том что с редаксом я не могу хранить состояние в виде объектов и связей между ними и моделировать бизнес-логику согласно DDD class User { id; posts = []; comments = []; constructor(data){Object.assign(this, data)} } class Post { id; comments = []; user; constructor(data){Object.assign(this, data)} } class Comment { id; user; constructor(data){Object.assign(this, data)} } var user = new User({id: 'user1', posts: [], comments: []}) var post = new Post({id: 'post1', user: user, comments: []}) user.posts.push(post); var comment = new Comment({id: 'comment1', post: post, user: user}) post.coments.push(comment) user.comments.push(comment)и потом где-то в редюсере state = {user: user} потому что получаются циклические ссылки из-за чего требование вернуть новый иммутабельный объект состояния в редаксе выльется в генерацию новых объектов всего состояния

попробуй нормализовать свои данные (normalizr вроде называется) тогда у тебя в сторе будут бакеты с сущностями и объекты ссылающиеся на них по айдишникам

Ввожу какие-нибудь значения в поле на котором висит обработчик - в redux-dev-tools видно что экшен кидается - но если смотреть diff между предыдущим стэйтом и текущим - нету разницы. То есть я в редюсерах вместо копирования и изменения копии стэйта изменяю сам стейт? Нарушается его "иммутабельность" и диффа в итоге нет? Или я снаркоманился и вообще не в этом причина? Оператор расширения использовал так как это показывают в примерах

у тебя console.log вызывается?

@bitaru сейчас гляну, забыл про него