Здравствуйте, AndyCyp, Вы писали:
AC>Тема, ни реакт, ни редукс не являются фреймворками, так как решают какие то одни задачи — рендеринг, и стейт менеджмент.
Ну ангулар как-то без ридуха обходился пока что и состояниями управлял. Но раз "каждый в Сиднее уже использует ридух", то и мы должны. Я вижу интересные бенефиты от ридуха, но я очень сомневаюсь, что "каждый в Сиднее использует ридух" думает о том же, что я.
Здравствуйте, DTB, Вы писали:
DTB>это не фреймворк, а как уже сказали обычный state manager, а точнее просто архитектурный паттерн.
Router чем не state manager? А до Router в ангулар 1 навигация производилась (сюрприз!) заменой состояний (State). Как я уже указал- потенциально от ридуха можно получить интересные фичи, но народ просто зазубрил это слово state manager и повтопяет с умным видом. Как повторяли "SOAP" например. DTB>штука полезная и прикручивают его не зря
Вот ты ее прикрутил- и какие фичи смог приделать, чего стандартные средства ангулара не позволяли?
DTB>пытался освоить через англоязычные туториалы, мозк отказывался, нашел нормальные статьи тут , после курения нормально улеглось
Здравствуйте, Тёмчик, Вы писали:
AC>>Тема, ни реакт, ни редукс не являются фреймворками, так как решают какие то одни задачи — рендеринг, и стейт менеджмент.
Тё>Ну ангулар как-то без ридуха обходился пока что и состояниями управлял.
Ангуляр не управлял состоянием. Для этого для него написано ажно несколько вариантов стейт-менеджмента.
Другое дело, что разработчики понаписывали сервисов-синглтонов, даже осмелились назвать это MVC и стейт менеджментом.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, DTB, Вы писали:
DTB>>это не фреймворк, а как уже сказали обычный state manager, а точнее просто архитектурный паттерн. Тё>Router чем не state manager? А до Router в ангулар 1 навигация производилась (сюрприз!) заменой состояний (State).
Роутер это только часть состояния. Те стейты, что в роутере, это не те стейты, что в стейтменеджменте. Где в роутере ты собираешься хранить, скажем, кеш или модель данных, состояние полу-десятка fetch-Запросов, состояние анимаций и тд ? Можно приспособить для этого роутер, но это будет как штаны через голову одевать.
>Вот ты ее прикрутил- и какие фичи смог приделать, чего стандартные средства ангулара не позволяли?
Это всего лишь архитектурный паттерн, а не фича. И не надо ждать фич от не-фичи. Редакс это одна из вариаций MVC, способ структурировать твой код
1 однонаправленый цикл обработки событий
2 иммутабельная модель вычислений
3 единый источник данных
4 изменение состояния отделено от асинхронщины
Преимущества — тестопригодный код, понятная, предсказуемая модель, единый способ реализации всех фич и тд.
Все это же можно и без редакса реализовать. То есть, тупо берем MVC из бородатых 90х и получаем ровно те же преимущества. Проблема с этим подходом ровно одна — вариаций MVC слишком много, а потому договориться с командой просто так не получится. А с редаксом все просто — 'angular-redux' или 'redux + thunk' и всем всё понятно.
В редаксе store.dispatch({type:'some action', payload: args})
а в MVC у нас будет controller.execute({command:'some action', args:args})
За асинхронщину в редаксе отвечает миддлвара, в MVC — сама же команда. Изменения применяет store, когда отработали редюсеры и мидлвары, в MVC — контролер, когда отработала команда. Как вариант — команда напрямую пишет в модель. Но этот вариант кривой, шо сабля.
Есть конечно реализации MVC, где контролер делает сразу всё и в ём никакие команды не выделены. Например прямо из обработчика лезем в базу и делаем там всё подряд. На самом деле такие реализации MVC никакие не MVC.
Здравствуйте, Ikemefula, Вы писали:
>>Вот ты ее прикрутил- и какие фичи смог приделать, чего стандартные средства ангулара не позволяли?
I>Это всего лишь архитектурный паттерн, а не фича. И не надо ждать фич от не-фичи. Редакс это одна из вариаций MVC, способ структурировать твой код I>1 однонаправленый цикл обработки событий I>2 иммутабельная модель вычислений I>3 единый источник данных I>4 изменение состояния отделено от асинхронщины
I>Преимущества — тестопригодный код, понятная, предсказуемая модель, единый способ реализации всех фич и тд.
I>Все это же можно и без редакса реализовать. То есть, тупо берем MVC из бородатых 90х и получаем ровно те же преимущества.
Ну т.е. от асинхронности страшно и потому надо заткнуть все в допотопный синхронный mvc из 90хх. Мне вот интересна фича записать действия пользователя вплоть до ввода с клавиатуры, и потом их проиграть. А всё, что ты перечислил- типичный блаб архитектора. Уверен, и про SOAP в своё время было тонны блаба, хоть это просто топорный xml.
Здравствуйте, Тёмчик, Вы писали:
Тё>Ну т.е. от асинхронности страшно и потому надо заткнуть все в допотопный синхронный mvc из 90хх. Мне вот интересна фича записать действия пользователя вплоть до ввода с клавиатуры, и потом их проиграть.
Это все в правильном mvc искаропки.
>А всё, что ты перечислил-
Еще раз и медленно — никакой паттерн фич не добавляет, это всего лишь другая структура того, что у тебя и так есть.
Есть у тебя запись событий, в редакс это одним способом, в mvc — другим, но оба будут похожи.
Скажем, мы вот не знали в 2007м году, что через 10 лет выйдет редакс, взяли да запись событий реализовали в контроллере. До смешного мало кода.
А потом добавили чендж-трекинг и снова обошлись смехотворным количеством кода.
И откат изменений получился, не знали, что это круче некуда.
Так какие фичи добавляет редакс? Подробнее, желательно аргументировать, почему это в mvc невозможно.
Здравствуйте, Ikemefula, Вы писали:
I>И откат изменений получился, не знали, что это круче некуда.
Undo/Redo по документу — примитив.
I>Так какие фичи добавляет редакс? Подробнее, желательно аргументировать, почему это в mvc невозможно.
Я указал- проиграть действия пользователя. Как он переходит по формам на сайте, кнопки нажимает, в какой момент времени и т.п. Можно составить модель поведения этого чела, например, понять, это тот же чел зашел в эккаунт, или кто-то другой.
Здравствуйте, Тёмчик, Вы писали:
Тё>Похоже, что надо его прикрутить. У кого какой экспериенс от сего фреймворка?
redux — это дефолтный выбор для реакт фронтэндов. Мы у себя в команде поставили этот выбор под вопрос, потому что уж больно странный этот redux. Проблемы
— Модификация состояния переусложнена. Вместо простого a=42 нужно писать много бесполезного кода.
— Нет нормального решения для инкапсуляции. Хотелось бы разбивать программу на отдельные модули, которые бы владели своими данными и скрывали некие секреты реализации. По умолчанию же предлагается доступ ко всему сырому состоянию + плоское глобальное простраство акшенов. Т.е. любой модуль по факту может читать и писать куда угодно. Тот redux код, что я видел — это лапша без разделения на какие-либо абстракции и инкапсуляции.
— Связано с предыдущим. Хотелось бы иметь осмысленные тесты для хорошо задезайненных модулей с мокингом соседних модулей. Вместо этого redux предлагает тестировать индивидуальные редюсеры, а мокинг отвергает вообще. Да, тестирование чистых функций просто, но мало-полезно если модуляризация хреновая.
— Сложные графы объектов нужно нормализовывать в сторе. Что выглядит странным ограничением, когда знаешь, что данные никогда не будут в БД.
— Стор не может включать состояние инкапсулированных 3rd-party объектов, таких как RTCPeerConnection. Т.е. состояние нужно дублировать, если хочется включить его в общий в data flow.
В результате, у себя в команде мы храним состояние в графе обычных классов, сделанных по обычным SOLID принципам. Презентационные объекты, которые видны из react-а, имеют некоторые ограничения, чтобы можно было против них написать фунцию типа mapStateToProps, как в redux.
Здравствуйте, Тёмчик, Вы писали:
I>>И откат изменений получился, не знали, что это круче некуда. Тё>Undo/Redo по документу — примитив.
С чего ты взял, что это было Undo/Redo по документу ?
I>>Так какие фичи добавляет редакс? Подробнее, желательно аргументировать, почему это в mvc невозможно. Тё>Я указал- проиграть действия пользователя. Как он переходит по формам на сайте, кнопки нажимает, в какой момент времени и т.п. Можно составить модель поведения этого чела, например, понять, это тот же чел зашел в эккаунт, или кто-то другой.
Ты наверное не читатель. Никакой такой фичи редакс не добавляет. В редаксе эта фича __реализуема__. В правильном MVC — тоже. Именно это мы и сделали 10 лет назад безо всякого редакса, смешным количеством кода.
Здравствуйте, SuhanovSergey, Вы писали:
Тё>>Похоже, что надо его прикрутить. У кого какой экспериенс от сего фреймворка?
SS>redux — это дефолтный выбор для реакт фронтэндов. Мы у себя в команде поставили этот выбор под вопрос, потому что уж больно странный этот redux. Проблемы SS>- Модификация состояния переусложнена. Вместо простого a=42 нужно писать много бесполезного кода.
Это компенсируется однозначными правилами реализации любых фич.
SS>- Нет нормального решения для инкапсуляции. Хотелось бы разбивать программу на отдельные модули, которые бы владели своими данными и скрывали некие секреты реализации. По умолчанию же предлагается доступ ко всему сырому состоянию + плоское глобальное простраство акшенов. Т.е. любой модуль по факту может читать и писать куда угодно. Тот redux код, что я видел — это лапша без разделения на какие-либо абстракции и инкапсуляции.
Именно. Редакс это не про хранение вообще всей модели в сторе. Если у вас тяжелая модель, то редакс должен делать только оркестрацию верхнего уровня.
SS>- Связано с предыдущим. Хотелось бы иметь осмысленные тесты для хорошо задезайненных модулей с мокингом соседних модулей. Вместо этого redux предлагает тестировать индивидуальные редюсеры, а мокинг отвергает вообще. Да, тестирование чистых функций просто, но мало-полезно если модуляризация хреновая.
Если вы пошли по пути тотал-редакс то вам никто ничем не поможет
SS>- Сложные графы объектов нужно нормализовывать в сторе. Что выглядит странным ограничением, когда знаешь, что данные никогда не будут в БД.
Не нужно.
SS>- Стор не может включать состояние инкапсулированных 3rd-party объектов, таких как RTCPeerConnection. Т.е. состояние нужно дублировать, если хочется включить его в общий в data flow.
Здравствуйте, Ikemefula, Вы писали:
I>>>И откат изменений получился, не знали, что это круче некуда. Тё>>Undo/Redo по документу — примитив.
I>С чего ты взял, что это было Undo/Redo по документу ?
«откат изменений» это что?
I>>>Так какие фичи добавляет редакс? Подробнее, желательно аргументировать, почему это в mvc невозможно. Тё>>Я указал- проиграть действия пользователя. Как он переходит по формам на сайте, кнопки нажимает, в какой момент времени и т.п. Можно составить модель поведения этого чела, например, понять, это тот же чел зашел в эккаунт, или кто-то другой.
I>Ты наверное не читатель. Никакой такой фичи редакс не добавляет. В редаксе эта фича __реализуема__. В правильном MVC — тоже. Именно это мы и сделали 10 лет назад безо всякого редакса, смешным количеством кода.
Да что это за фича такая? Вои мне чел показал демку деруха- книго-магазин, плагин для хрома установил, там кнопки перемотка-пауза-пуск и т.д. Потыкал кнопками в книго-магазине. Потом в плагине хрома отмотал назад и запустил- оно проигралось снова. Я понимаю, что демки делают чтоб подчеркнуть крутизну и скрыть проблемы, но всё же это сил но действует на неокрепшие умы, например, менеджеров разработки- не им же потом с редухом трахаться. А это твоё контроллер-экзекут- это скорее очередь сообщений. Контроллер исполняется команды-сообщения, это блин вообще винапи из самой первой форточки так работало.
I>Вот редакс I>
I>Берем параметр и сохраняем. Потом это можно проиграть.
Гугл протобуфер. В нём даже классы названы «сообщениями».
I>В MVC для этого надо создать декоратор или наследник контроллера, который сделает всю работу.
Ни то и не другое. Визитор.
I>Количество кода примерно одинаково.
Вопрос же не про количество кода, а «изкоробочная» запись последних действий пользователя, например, перед ошибкой в программе.Эту последовательность действий потом проиграть разработчику, чтобы воспроизвести баг.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, SuhanovSergey, Вы писали:
Тё>>>Похоже, что надо его прикрутить. У кого какой экспериенс от сего фреймворка?
SS>>redux — это дефолтный выбор для реакт фронтэндов. Мы у себя в команде поставили этот выбор под вопрос, потому что уж больно странный этот redux. Проблемы SS>>- Модификация состояния переусложнена. Вместо простого a=42 нужно писать много бесполезного кода.
I>Это компенсируется однозначными правилами реализации любых фич.
Не компенсируется, т.к. цена не соответствует полезности. И немного непонятно, что эта маркетинговая фраза вообще значит. Думаю, это способ как-то продать чистоту редюсеров. Проблема в том, что redux навязывает чистоту и immutability, неважно подходит, этот подход к проблеме или нет.
SS>>- Нет нормального решения для инкапсуляции. Хотелось бы разбивать программу на отдельные модули, которые бы владели своими данными и скрывали некие секреты реализации. По умолчанию же предлагается доступ ко всему сырому состоянию + плоское глобальное простраство акшенов. Т.е. любой модуль по факту может читать и писать куда угодно. Тот redux код, что я видел — это лапша без разделения на какие-либо абстракции и инкапсуляции.
I>Именно. Редакс это не про хранение вообще всей модели в сторе. Если у вас тяжелая модель, то редакс должен делать только оркестрацию верхнего уровня.
Как раз наоборот, Single source of truth и всё такое. rtfm: The state of your whole application is stored in an object tree within a single store.
Использовать redux + что-то ещё для сущностей, что redux не может прожевать, нет смысла. Нужно испольовать только это что-то, и не добавлять лишних фреймворков.
SS>>- Сложные графы объектов нужно нормализовывать в сторе. Что выглядит странным ограничением, когда знаешь, что данные никогда не будут в БД.
I>Не нужно.
Предположим, нужно хранить граф не дерево
A -> B
B -> C
A -> C
Когда C обновляется, нужно как-то найти все сылки на него и обновить. Технически, это возмножно, но непрактично и неэффективно. Остаётся хранить ссылки в виде id + отображения id->реальный объект. Если следовать этому принципу последовательно, то получаться нормализованные данные.
Тё>Похоже, что надо его прикрутить. У кого какой экспериенс от сего фреймворка?
использовал его в аппе где стейт был одним большим деревом которое надо было (де)сериализовывать по разным поводам (т.е. у меня по внешними причинам и так уже были ограничения которые бы мне редукс навязал). получилось многословно, но вроде терпимо. не уверен, зачем это люди используют для всего — я бы не стал.
Здравствуйте, Тёмчик, Вы писали:
I>>С чего ты взял, что это было Undo/Redo по документу ? Тё>«откат изменений» это что?
По простому, это как транзакции — взял да отменил.
I>>Ты наверное не читатель. Никакой такой фичи редакс не добавляет. В редаксе эта фича __реализуема__. В правильном MVC — тоже. Именно это мы и сделали 10 лет назад безо всякого редакса, смешным количеством кода.
Тё>Да что это за фича такая?
Запись всех действий пользователя, что бы их можно было проиграть в другой раз.
>Вои мне чел показал демку деруха- книго-магазин, плагин для хрома установил, там кнопки перемотка-пауза-пуск и т.д. Потыкал кнопками в книго-магазине. Потом в плагине хрома отмотал назад и запустил- оно проигралось снова.
Ну вот нажал ты кнопку, книга вжик, и купилась. Как это редаксом отмотать назад, если деньги с карточки уже списаны ?
>А это твоё контроллер-экзекут- это скорее очередь сообщений. Контроллер исполняется команды-сообщения, это блин вообще винапи из самой первой форточки так работало.
Не угадал. Реализация MVC была считай один в один как в редаксе, только модель мутабельная, но серилизуемая, клонируемая.
I>>Вот редакс I>>
I>>Берем параметр и сохраняем. Потом это можно проиграть. I>>В редаксе для этого надо написать энхансер, который сделает всю эту работу.
I>>Вот MVC I>>
I>>Берем параметр и сохраняем. Потом это можно проиграть. Тё>Гугл протобуфер. В нём даже классы названы «сообщениями».
Не надо никаких протобуфферов.
I>>В MVC для этого надо создать декоратор или наследник контроллера, который сделает всю работу. Тё>Ни то и не другое. Визитор.
Ты лучше меня знаешь, чего у меня в коде было ?
Что бы воспроизвести действия пользователя, надо просто проиграть команды вида {command:'some action', args:argumets}. И всё.
I>>Количество кода примерно одинаково.
Тё>Вопрос же не про количество кода, а «изкоробочная» запись последних действий пользователя, например, перед ошибкой в программе.Эту последовательность действий потом проиграть разработчику, чтобы воспроизвести баг.
Здравствуйте, SuhanovSergey, Вы писали:
SS>>>redux — это дефолтный выбор для реакт фронтэндов. Мы у себя в команде поставили этот выбор под вопрос, потому что уж больно странный этот redux. Проблемы SS>>>- Модификация состояния переусложнена. Вместо простого a=42 нужно писать много бесполезного кода.
I>>Это компенсируется однозначными правилами реализации любых фич.
SS>Не компенсируется, т.к. цена не соответствует полезности. И немного непонятно, что эта маркетинговая фраза вообще значит. Думаю, это способ как-то продать чистоту редюсеров. Проблема в том, что redux навязывает чистоту и immutability, неважно подходит, этот подход к проблеме или нет.
Redux никто не предлагает применять везде и тотально. Это лично ты так решил для себя. Если чистота и иммутабельность не подходит, значит редакс не применим.
И вот если применение редакса оправдано, то профин именно в том, что все фичи ты пилишь одинаково. То есть, про любую хотелку ты наперед знаешь, как её запилить.
SS>>>- Нет нормального решения для инкапсуляции. Хотелось бы разбивать программу на отдельные модули, которые бы владели своими данными и скрывали некие секреты реализации. По умолчанию же предлагается доступ ко всему сырому состоянию + плоское глобальное простраство акшенов. Т.е. любой модуль по факту может читать и писать куда угодно. Тот redux код, что я видел — это лапша без разделения на какие-либо абстракции и инкапсуляции.
I>>Именно. Редакс это не про хранение вообще всей модели в сторе. Если у вас тяжелая модель, то редакс должен делать только оркестрацию верхнего уровня. SS>Как раз наоборот, Single source of truth и всё такое. rtfm: The state of your whole application is stored in an object tree within a single store.
Что, и весь серверс сайд вместе с клаудом баз данных в браузеный редакс запихать ? Здесь речь про веб приложения, у которых большая часть состояния находится где то еще. То есть, редакс контролирую только часть всего состояния.
Если у вас конская модель, то один вариант, согласно rtfm, это total redux, и он не палит, что уже давно известно. Второй вариант — ограничить редакс только той частью, где вьшки.
SS>Использовать redux + что-то ещё для сущностей, что redux не может прожевать, нет смысла. Нужно испольовать только это что-то, и не добавлять лишних фреймворков.
Наоборот. Уже давно известно, что total redux не летает. Но вы еще изобреаете у себя эту истину.
SS>Когда C обновляется, нужно как-то найти все сылки на него и обновить. Технически, это возмножно, но непрактично и неэффективно. Остаётся хранить ссылки в виде id + отображения id->реальный объект. Если следовать этому принципу последовательно, то получаться нормализованные данные. SS>Есть друго решение для не-деревьев?
Здравствуйте, koenig, Вы писали:
K>использовал его в аппе где стейт был одним большим деревом которое надо было (де)сериализовывать по разным поводам (т.е. у меня по внешними причинам и так уже были ограничения которые бы мне редукс навязал). получилось многословно, но вроде терпимо. не уверен, зачем это люди используют для всего — я бы не стал.
Потому что очень четкая схема. Многословная, но зато девелоперов можно сразу пускать в код, а не ждать, пока они пять лет будут скил "понимание MVC" качать. С MVC одна проблема — вариаций столько, что большинство даже определить не может, MVC или нет. И называют этим словом сложную систему палочек и веревочек на синглтонах и эвентах.
Ты лучше меня знаешь, чего у меня в коде было ?