оу оу оу палехче)

на самом деле со стейтом понятно почему он один - потому что это одна юзерская сессия

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

ну ты что бота ни разу не писал чтоле

Смотря какого. Например бот на тестовую рпг отлично лёг бы на редакс

поэтому сейчас это выглядит как типа не буду я делать один кабинет с терминалом для получения бланков для получения услуги, а буду я делать офис на 100 окон в котором будут 100 операторов для получения любой услуги. короч надо вкладывать вещи типа Date.now в тот же уровень в котором например будет user.loggedIn

Смотря какого. Например бот на тестовую рпг отлично лёг бы на редакс

ты видел меканим в юнити?

там ж были вложенные стейты вроде?

ща короч ссылку тебе найду, там дальше сам

стара как мир, и да, там не только HFSM но и вложенные автоматы - http://aigamedev.com/open/article/hierarchical-or-nested-fsm/

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

более того, если ты прочтешь справочник UML 2 версии и походишь по ссылкам - и реализуешь - там понятно будет что вообще выносить экшны на уровень выше (как в случае редакса) - как минимум плохое архитектурное решение

может, это мое ИМХО, если что - коллеги скажут

но мне кажется так

там ж были вложенные стейты вроде?

Вложенные стейты не позволяют, как минимум ввести в едином месте программы логгер всех изменений стейтов в системе

Потому я за глобальный стейт

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

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

Ну, почитай ридми моей либы - я реализовал вложенные автоматы без вложенных стейтов

я прочту, но ты мне скажи - что ты с этого получил?

если кучу перцептронов то поздравляю. ты изобрел switch ... case) ну, по сути

я прочту, но ты мне скажи - что ты с этого получил?

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

Например, у меня есть автомат игрока, который не знает о структуре стейта игры. А в игре несколько таких игроков (это мой кейс)

можно вопрос?

если ты не играешь в Screeps - на кой хер ты это делал на редаксе???

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

тем более если слова про игрока и про игру актуальны

вот нахера?

можно вопрос?

Конечно. Только связь попадает - я в дороге

я уже написал дальше, сорян)

вот нахера?

Чтоб не было в коде привязки к тому, какой именно это игрок. Я заметил, что без этого проверка индекса игрока слишком часто возникает в коде - разве это гуд?

ок, в твоем случае стейт - это стейт игрока который играет?

глобальный стейт

глобальный стейт

Глобальный стейт - стейт приложения - пока что это игра, потом добавлю конфиги в стейт. Легко расширять, когда не привязан к структуре глобального стейта

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

Глобальный стейт - стейт приложения - пока что это игра, потом добавлю конфиги в стейт. Легко расширять, когда не привязан к структуре глобального стейта

игра я имею ввиду клиент? в этом вопрос

@zerobias чекни hfsm

Потому я за глобальный стейт

Эээээээ

@zerobias чекни hfsm

+

+

Я уже сделал hfsm ?

Я уже сделал hfsm ?

Там просто fsm

Там просто fsm

Где ты видел fsm которые вкладываются и пересчитываются друг относительно друга?)

чем отличаются Hierarchical Finite State Machine и Nested Finite State Machine ?

Там просто fsm

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

https://github.com/zerobias/effector/blob/develop/src/effector/__test__/__snapshots__/index.test.js.snap Вот я отдельно тестировал корректность построения дерева зависимостей

Доставляет количество скобок

Вот мой тест на мою реализацию hfsm: https://github.com/blackakula/redux-composite/blob/master/examples/dispatch.js

лесенки )

Доставляет количество скобок

Естественно, это же и есть дерево зависимостей

Для этого ниже человекочитаемый рендер, это тот же самый код

Compute это либо сторы, либо вычисления (map) перед ними

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

Естественно, это же и есть дерево зависимостей

А как же encapsulation? Как насчёт того, чтоб быть agnostic к структуре подсистем?

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

Я тоже не прогоняю по всем - мне это просто не нужно by design

Редакс не спрашивает, прогоняешь ты или нет

А как же encapsulation? Как насчёт того, чтоб быть agnostic к структуре подсистем?

По барабану какая форма у стора, библиотеке это абсолютно безразлично

Редакс не спрашивает, прогоняешь ты или нет

Если речь о combineReducers, то да - но я это не использую. Кроме того, combineReducers не решает проблему коллизии, если у тебя две подсистемы на одном редьюсере основаны

Кстати, у меня можно даже кастомизировать equality проверку для стейта подсистемы: https://github.com/blackakula/redux-composite/blob/master/README.md#equality Соответственно, триггеры не будут выполняться, если по equality стейт не изменился

Dto - тупая структура данных, которая имутабельна и может только максимум сериализовать себя, верно? А vo - структура данных по умнее, тоже имутабельна, но имеет в себе поведение ещё

dto необязательно имутабельна

Почему?

обсуждали тут много про это дня два назад. пролистай.

Ок, спасибо

dto в чистом виде - массивчик на стероидах

все остальное - это уже от лукаVOго

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

Парни. А маппер не должен же содержать операции над коллекциями сущностей? И метод find к примеру не нужен же в нём, это все в репозитории должно быть?

Т.е типичный флоу: поступает запрос обрабатывается в контроллере вызывается апликейшн сервис в нем с помощью репозитория получаем сущности выполняем над ними какие либо операции перстистим результат с помощью репозитория(который может как использовать внутри себя маппер а может и нет)

у вас так?

у вас так?

Неа У меня все контроллер делает

Но, почему-то, все говорят, что я говнокодер

Но, почему-то, все говорят, что я говнокодер

контроллер - это хороший менеджер. А хороший менеджер делигирует работу.

(ну то есть я не вижу смысла вводить application-level сервисы там где есть только контроллеры)))

(ну то есть я не вижу смысла вводить application-level сервисы там где есть только контроллеры)))

Как говорил великий человек: зачем писать тесты, если у тебя в проекте только контроллеры

Как говорил великий человек: зачем писать тесты, если у тебя в проекте только контроллеры

зачем вообще такой проект писать?)

зачем вообще такой проект писать?)

Тестовое раз в год могут попросить

Мне "покормить" контроллеры не жалко :)

т.е направление зависимостей получаетс такое( => читать как внедряется в ): SomeEntityMapper => RepositoryInterface => SomeApplicationService т.е маппер это вообще вспомогательная штука на инфраструктурном слое которая изолирует по возможности нас от общение на языке хранилища напрямую

ребят, а вот скажите. вот допустим картинка http://www.csci.csusb.edu/dick/samples/links.png

я понимаю что knows это типа храним ссылку на объект, а uses - вот это что с точки зрения кода?

напрямую вызов без хранения зависимости?

Не туда посмотрел

Uses - зависимость, нет?

суп

есть два стула /user/:userId/subs/link/:linkId - userId для пользователя свой, для админа любой, у link есть свойство userId, которое чекается. Запрос к другому userId или linkId вернет - 404 /user/subs/link/:linkId - тоже самое, но userId берется из сессии

в первом варианте тоже к сессии придется обратиться, чтобы чекнуть userId

есть ещё третий стул, это админка и либо делать единый REST endpoint (первый вариант), либо два (приватный и публичный, второй + первый)

Uses - зависимость, нет?

а что есть зависимость

а что есть зависимость

То что на стороне стрелки

ну вроде как да

Rest endpoint :3