Comments 51
Где человеческое разделение на container/presenter?
Где ES2015/ES7 через babel? Куда удобнее использовать array/object spread, вместо нагораживания immutable.
Где stateless function components, которые в скором времени будут выступать в роли де-факто presenter'ов?
Про валидацию props слышали?
/me подумывает о серии статей по bleeding-edge development with redux.
Ток написал об этом, а вы опередили, — жаль ребят из mail'а.
А это просто перевод, он не призывает к действию и не отражает процессы проходимые в mail.ru )
А давайте, сделайте этот же пример с применением всего вами перечисленного. Хорошо бы ещё снабдить это всё комментариями, какие плюсы и минус это дает.
P.S. Можно без тестов, да и детализация такая не нужна.
Напишите, потому что я только месяц назад прочитал эту статью и считаю/считал что она шикарна и прямо труъ труъ. А то остальные туториалы ещё хуже.
Один только immutable.Record дает очень многое
Не надо забывать, что
class Car {
constructor(manufacturer, model, speed) {
this.model = model;
this.manufacturer = manufacturer;
this.speed = speed;
}
getTitle = () => `${this.manufacturer} ${this.model} ${this.speed}км/ч`;
}
const myCar = new Car('Lada', '2101', 100);
console.log(myCar.getTitle()); // Lada 2101 100км/ч
const modifiedCar = {...myCar};
console.log(modifiedCar.getTitle()); // undefined
console.log(myCar instanceof Car)// true
console.log(modifiedCar instanceof Car)// false
E.g.: immutable не создает новый объект, если данные реально не были изменены, spread — создаст.
Можно же проверить, изменились ли данные и вернуть новый объект через spread
Что оптимизировать, если state объекты примитивны?
Разве immutable-js может работать с прототипированными объектами? Есть пример? Но если даже так, я в реальных приложениях store поддерживаю примитивным, ведь это как хранилище данных.
p.s.: хранилище данных может быть сложным, если, например, нужно повторить «структуру БД», а если еще и несколько схем, то все усложнится в разы. это все application specific и выбирать инструмент нужно по требованиям.
Изначально комментарий был про то, что результаты у spread и immutablejs не всегда одинаковые и нужно это понимать и использовать то, что лучше подходит.
Когда лучше подходит immutable-js? Думал вы утверждаете, что immutable-js для сложных store, но и вы его в такой ситуации не используете. Хм.
А это проще (и другие критерии), чем среагировать на нужный action.type соответствующего модуля для синхронизации? То что состояния для разных компонентов должны быть синхронизированы есть частный случай. Были попытки автоматизировать синхронизацию, но практика доказала, что луче всеми силами отставить простоту без магии.
{ name: 'aaa', age: 10, email: 'spam@spam.it', .....}
прилетает запрос на выставление age в 10 или даже на age + email. Данные не поменялись, но запрос прилетел. Можно сделать spread:
{ ...state, ...action.updates}
и получим новый объект (данные не поменялись на самом деле, прилетел запрос на изменение такой: { age: 10, email: 'spam@spam.it'). immutable вернет тот же объект.
/me подумывает о серии статей по bleeding-edge development with redux.
"Уж полночь близится, а Германа всё нет"
Закидают помидорами, но:
React.createClass
и используете babel ?- Mixin'ы — если ваше приложение не должно работать на
React.Native
то зачем ? JSDom
— зачем ?bindActionCreators
?- Почему не показали принципы умных и глупых компонентов ?
combineReducers
?- 0.14 React?
- Universal app ?
- Актуальность данной работы ?
Я похоже очень плохо понимаю redux
, и мне кажется я очень неправ как и этот парень со своими уроками, вон выше то статья, — как статья. Все понятно, — доходчиво то как.
Мы совсем не учимся и не смотрим/читаем что нам дают.
Прости нас Даниил, прости пожалуйста.
«приложение для «живых» голосований» в тысячи строк кода? спасибо не надо.
такое пилится в несколько десятков строк кода на чистом JS
без всяких реактов и редаксов и прочей мути.
expect(winner).to.be.ok;
Никогда не понимал, откуда появилася дурацкая идея писать через точку это. Да еще и нестрого (можно пропустить to и be) Чем оно лучше
toBeOk()
? Тем, что подсвечивается как ошибка и не автодополняется в IDE? Тем, что в команде кто-то будет писать .to.equal
, кто-то .to.be.equal
? Дополнительная нагрузка на код-ревью. Ради чего? Просто чтоб понты поколотить? Непоследовательность даже в официальной документации:
expect(Chai).to.be.an.instanceof(Tea);
expect([ 1, 2, 3 ]).to.be.instanceof(Array);
То необходимо ставить an или нет?
Надеюсь, эта дурацкая мода быстро пройдет.
Прелесть в том, что можно писать expect(Chai).instanceof(Tea); или expect(winner).ok;
Всякие .to.be.an — просто сахар для граммар-наци
Хороший материал, но многовато за один раз. Лучше бы разбить на 2-3 статьи.
Вопрос по одному из принципов redux архитектуры — по требованию хранить все состояние программы в одном объекте. Допустим, есть большая модульная программа, которая имеет несколько сборок с различной комбинацией этих модулей. Как достичь независимости модулей если у них всех один общий state? В классическом ООП модуль полностью изолирует и свой state и свое поведение за счет инкапсуляции классов, а связь между модулями устанавливается специальным кодом, вне модулей.
Вообще сложилось мнение, что redux подходит только для небольших проектов, со своей спецификой. Например, где данные сильно не привязаны к способам их изменения.
1) Никто не мешает модулю иметь свой state, он может быть отдельно написанным приложением со своим API, и не обязательно написан с Redux
2) Проблема в общем то надуманна, т.к. если программист написал два модуля и их state пересекаются, то Redux не виноват. Так можно постараться написать с любым стеком. У модуля своя зона ответственности в state, он должен зависеть только от нее, а для взаимодействия с общим состоянием есть Actions, которые изолированы от state
https://facebook.github.io/immutable-js/docs/#/Listf
(f лишняя на конце)
Руководство по работе с Redux