Вообще всем

Аргумент

Аргумент

Чем он нахлабучивает священный редух?

Ну а че, перечислять тебе? Там много пунктов

Ну когда за чёт базарят обычно доказывают свою точку зрения, а если сказать нечего тогда и не надо было начинать

Ну когда за чёт базарят обычно доказывают свою точку зрения, а если сказать нечего тогда и не надо было начинать

Выше мое сообщение

Я твои сообщения по сове искать должен?) где то ещё друг попугай был)))

Я твои сообщения по сове искать должен?) где то ещё друг попугай был)))

Ты либо читай чат, либо молчи

@risenforces классный ник

децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи — сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд — сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения — принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст — возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты — независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты — предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch в эвентах, можно догадаться, что делает функция .watch у стора — приложение строится из комбинации базовых элементов и возможности строить новые. нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

Выше мое сообщение

Если он на столько хорош, чего не хайпим? Подозрительно, написать можно много, пруфы где?)

а чем mobx на проксях плох !11111

а чем mobx на проксях плох !11111

Тормозами?))

ты видел там реализацию computed

Кстати в последнее время реально много стейт менеджеров начали делать

Хз с чего ты решил, что надо хайпить

Мне хватило обрыва циклических вычислений

Больше хайпа - больше развития. Это же попробуй найти кто твой код после тебя поддержать сможет.

Последнее время и арталар где-то рядом?

Это не так работает.

Мне хватило обрыва циклических вычислений

С удовольствием вычитаю ( аля выслушаю ) твои доводы)

Какие сейчас расценки на ревью?

Поддержку и развитие не дают пользователи библиотеки

Открой занавес, буду благодарен за расбитую иллюзию

Хм, ну, есть вероятность, что с увеличением количества юзеров увеличится количество ussues/pr.

Хм, ну, есть вероятность, что с увеличением количества юзеров увеличится количество ussues/pr.

У тс дохрена юзеров Но уже который год опшнл чейнинга нет, ишуи не помогают

А, так это просто тс говно. 🌚

Согласен но пример не единственный

децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи — сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд — сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения — принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст — возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты — независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты — предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch в эвентах, можно догадаться, что делает функция .watch у стора — приложение строится из комбинации базовых элементов и возможности строить новые. нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

Много громких красивых слов, но: - не вижу проблем добавлять в редаксе столько редьюсеров сколько понадобится - совмещать сторы? Смысл? Нельзя обратиться в компоненте сразу к двух сторам? - меньше условий - быстрее работает. Подход редуха правильнее с точки зрения осведомлённости сторов.. так можно прое*бать что-то - бизнес логику нужно выносить из сторов, из экшенов, из миддлвейров в отдельные классы/хелперы/утилы, а не разводить помойку... всё лишь бы не тестировать - редух тоже использует только объекты - зеркальный подход - какая-то нескрываемая ненависть к редуху... в сообществе нужно поддерживать друг друга, а не хаять другие проекты.. за счёт этого далеко не поедешь

Вот ты пользуешься парой тысяч библиотек, многим ты помог?

Много громких красивых слов, но: - не вижу проблем добавлять в редаксе столько редьюсеров сколько понадобится - совмещать сторы? Смысл? Нельзя обратиться в компоненте сразу к двух сторам? - меньше условий - быстрее работает. Подход редуха правильнее с точки зрения осведомлённости сторов.. так можно прое*бать что-то - бизнес логику нужно выносить из сторов, из экшенов, из миддлвейров в отдельные классы/хелперы/утилы, а не разводить помойку... всё лишь бы не тестировать - редух тоже использует только объекты - зеркальный подход - какая-то нескрываемая ненависть к редуху... в сообществе нужно поддерживать друг друга, а не хаять другие проекты.. за счёт этого далеко не поедешь

У тс дохрена юзеров Но уже который год опшнл чейнинга нет, ишуи не помогают

опшнал чейнинга не будет, пока он не станет стандартом es, на текущий момент пропозал в stage 2

которые еще и спеку поменяли

а декораторы тогда почему есть ?

не ко мне вопрос

ну я ответил на твой аргумент

Множественные сторы ридакса невозможно поддерживать в консистентном состоянии. Если есть два стора, то появится между ними и зависимость. Как ты это решать с ридаксом собрался неизвестно. Слушать всем все это убийство производительности. Зачем обновлять все, если можно не обновлять. Ну допустим нужно разделить Вью на две части. Причем тут ридакс. И вообще какая такая острая необходимость разделять?

Для этого нужно грамотно строить архитектуру приложения Immutable решает проблему При том, что ты предлагаешь подход вынести логику в стор

Много громких красивых слов, но: - не вижу проблем добавлять в редаксе столько редьюсеров сколько понадобится - совмещать сторы? Смысл? Нельзя обратиться в компоненте сразу к двух сторам? - меньше условий - быстрее работает. Подход редуха правильнее с точки зрения осведомлённости сторов.. так можно прое*бать что-то - бизнес логику нужно выносить из сторов, из экшенов, из миддлвейров в отдельные классы/хелперы/утилы, а не разводить помойку... всё лишь бы не тестировать - редух тоже использует только объекты - зеркальный подход - какая-то нескрываемая ненависть к редуху... в сообществе нужно поддерживать друг друга, а не хаять другие проекты.. за счёт этого далеко не поедешь

Во первых парой без тысяч. А во вторых с годом-полтора опыта с яп без тех. образования, я разве могу что-то годное залить в пулл-реквест? Я вот с нетерпением жду момента, когда увижу что пофиксить, или придумаю что-то интересное в пулл-реквест)