Ramil Z.: напишите мне в личку, если вас это не затруднит. Мне как раз нужен кто-то кто только учится ангуляру (почитать статейку и сказать что не понятно)
Ramil Z.: да, все должно быть директивой, все подсчеты и т.д. должны быть в контроллере. Фильтры можно использовтаь как чистые функции для форматирования вывода но не более того.
copal: flux это не новая концепция. Это набор известных идей которые скопоновали в единую кучу. Можно воспринимать flux как MVC + Event Sourcing.
Оносная идея - MVC нужен только если у нас есть мутабельное состояние что бы контроллеры просили модель поменять состояние, а вьюшка бы подписывалась на изменения оных (вроде как даже вы мне доки 79-ого года скидывал на эту тему).
Если у нас состояние не мутируется - то все предельно упрощается.
Redux - это реализация Flux. Термины - не столь важны, важна идея. Состояние системы формируется (редьюсерами) из последовательности действий (ивентов, экшенов, команд, термин не важен). Это не измененное предыдущее состояние, это новое состояние которое ничего не знает о предыдущем.
в итоге приходим к простой функции - UI = f(state); где f - это чистая функция которая не имеет состояния. В этом случае нет возможности получить побочные эффекты изменения состояния где-то внутри UI компонентов. Ну и конечно же все красиво только в теории, на практике прокидывать вообще все состояние может быть не столь эффективным. Пример - кропалка картинок. По хорошему вы на каждое смещение курсора должны формировать заного состояние всей системы. Согласитесь, это не очень эффективный подход.
Вывод - функциональное программирование работает (как красивая математическая теория) исключительно в условиях неограниченности вычислительных ресурсов. Для 95% задач WEB-а это достаточно, для оставшихся 5-ти приходится мутировать состояние поближе к источнику экшенов.
copal: я не помню. Двусторонний датабиндинг никакого отношения к MVVM не имеет. Двусторонний датабиндинг это два односторонних биндинга. MVVM привносит только концепцию биндингов, как их используют - это уже на совести разработчиков. Вы можетепускать данные строго в однусторону сохраняя имутабельность, можете пускать в обе стороны (как сделано в ангуляре по умолчанию) и т.д.
Но биндинги это попытка упростить отслеживание изменений в моделях. React с его Flux-ом пошли чуть дальше - если нет "изменений состояния" то биндинги предельно упрощаются. Вместо изменения состояния мы просто получаем новое состояние на основе предыдущего и какого-то экшена. То есть - идея event sourcing в действии.
Повторюсь - развитие всех этих идей надо привязывать исключительно к ограничениям, с которыми эти вещи призваны бороться. 40 лет назад Flux для построения UI было слишком не эффективно так как стоимость памяти была слишком высока. Проще было мутировать состояния. Сегодня - проще генерить состояние как измененнную копию старого.
copal: расширяйте кругозор. Все идеи которые популярные сегодня продвигаются с 60-х.
По поводу различий в подходах и тд. Есть ООП допустим и есть функциональное программирование котороые сейчас набирает популярность. Так вот, функциональное программирование старше! Просто 50 лет назад оно было неприменимо на практике потому что для имутабельности данных это было банально слишком дорого и неэффективно. Но сегодня - это нормально. Оперативки стало больше, появилась возможность паралелить выполнение и с этим возникли вопросы синхронизации мутаций и тд. А если у нас данные не меняются - то нет проблем с отслеживанием изменений.
Теперь о задачах и различиях в них. Если брать игрушку - то текущее состояние - это огромное множество переменных и тд. которые меняются по десятку раз в секунду и могут достигать по сотне мегабайт на кадр. Согласитесь, мутировать состояние в этом контексте явно эффективнее чем 60 раз в секунду копировать все состояние и строить его по новой. Да, это возможно с функциональными подходами но добавляет очень много сложности с мемоизацией и т.д. и в итоге игры могли бы писать только люди со степенями в CS (Computer Sience).
Но если мы берем типичное web приложение - там состояние меняется намного реже, и все состояние на странице можно уложить в мегабайт, а копирование мегабайта раз в секунду - это копейки. Потому с подходами с имутабельными данными можно здорово так понизить сложность приложения. То есть в этом плане состояние это предыдущее состояние + экшен. И мы так можем продолжать рекурсивно разбивать это до state = null + action. Цепочка состояний, цепочка ивентов, цепочка действий, цепочка команд... называйте как хотите.
Так же - хороший пример где нужна производительность и сохранность данных, всякие автоматические трейдинги и т.д. У нас тут мало мутаций но нужно делать много выводов на основе изменений данных во времени. В этом плане намного выгоднее хранить все как огромную цепочку событий (экшенов) и анализировать их уже после.
Как-то так. На этом предлагаю завершить дискуссию. Если вам интересно - переходите в личку.
copal: Хватит делать глупые догадки о вещах которые вы не понимаете. Посмотрите лучше лекцию. Займет час вашей жизни и вы сможете наконец понять что такое EventSourcing, что такое CQRS и когда это все нужно, для чего нете профит и т.д.
copal: кругом заговор, рептилойды придумали MVVM что бы снизить продуктивноть а ведь можно все проблемы решать единый православным ECS на который фапают в геймдеве. Ведь то что решает их проблемы решает проблемы всех! Еритики! Есть только один верный путь!
Вот как-то так ваши доводы звучат.
p.s. И не путайте импреративную процедурщину и функциональщину. Если вы к этому всему плохо относитесь то это от незнания.
Грег Янг в индустрии провел лет 20, было бы странно если бы его как гражданина США не занесло в Microsoft или он не сталкнулся с работой в .NET (как никак половина банков используют именно .NET как основной стэк технологий). (причем я не припоминаю что бы он в microsoft работал, да и мне это не интересно).
У Microsoft еще относительно недавно была весьма странная политика. Взять тот же C# .NET. Это очень мощный инструмент, а язык весьма выразительный и красивый. Так же есть F# для любителей функциональщины.
Если бы изначально microsoft не была столь привязана к своей платформе, то кто знает что было бы с Java и какую долю оно бы занимало в энтерпрайз сегменте рынка. Но последние пару лет microsoft активно выкладывает все наработки по своей платформе в опенсурс, что подразумевает что ближайшие пару лет можно ожидать роста .NET платформы.
Ну и в целом политика компании со сменой руководства мне лично нравится.
А те кто смеются с шиндусятников... они с шиндусятников смеются а не с windows там.
hcvbhc: если вы МОЖЕТЕ послать IP пакет с одной машины на другую - то вам не нужен сервер. Если вы НЕ МОЖЕТЕ этого сделать (потому что машины находятся за разными NAT и это не статические IP) - то вам нужен сервер для того что бы эти две машины могли через одну известную точку найти друг дружку.
Почитайте про TCP/IP а именно адресацию в сети, P2P и т.д. С IPv6 необходимость в NAT и т.д. отпадет но до этого надо дожить еще.
iid0001: можно промежуточное состояние хранить в redis например. То есть у нас один сервис обсчитывает состояние ботов а другой сервис просто забирает состояние ближайших. У редиса есть возможность в качестке клюей использовать геохэши, за счет чего можно оптимизировать выборки по координатам. Но надо думать.
Вообще не факт что это даст профит, тут все сильно зависит от того как это можно разделить. Я бы подумал о том как все это ложится на ECS (Entity Component System) и можно ли поделить каждый компонент на отдельный процесс и как следствие - повыносить все это добро.
Для игр все чуть сложнее чем для обычных приложений.
