да, action creator, а что он еще должен делать кроме передачи данных? Изменением state занимается reducer.
Я немного перепутал с api файлом, у меня есть еще кастомный хук, в котором я держу инфраструктуру Redux Toolkit по модалам.
Я создал его один раз и использую по всему коду. Равно как и глобальный стор я создаю один раз и при создании нового слайса просто добавляю две строчки к глобальному стору.
Вы видите остальные 4 способа в документации Redux Toolkit? Допустим, если я не работал с этой библиотекой, я открываю документацию и вижу один способ. Зачем мне выбирать из 4 способов, о которых я не знаю и о которых там не пишут?
давайте опустим kr-observable, если вы не против. Как я говорил, я не специалист в этой библиотеке.
Если вы сталкивались со случаями низкой производительности Redux, прошу Вас поделиться опытом, что за тип приложения вы разрабатывали, как именно проявлялась деградация производительности, что вы предпринимали для того, чтобы понять корневую причину проблемы? Для сообщества Хабра это было бы ценной информацией.
В ваших примерах со счетчиками – Redux Toolkit имеет несколько дополнительных строк кода по сравнению с Mobx. Это нормально. Во-первых, количество строк кода не равно простоте его поддерживания. Вы можете написать совершенно кривой и неподдерживаемый код на 10 строках, и иметь простой и ясный код на 15 строках.
Больше того, примеры со счетчиками я не считаю корректными в принципе, потому что они не имеют тех проблем, которые имеют коммерческие продукты. Несколько человек не работают над счетчиками одновременно, счетчики не содержат сложной оркестрации HTTPS запросов, их данные не должны переиспользоваться в разных местах. Счетчикам в принципе не нужен state management, им достаточно локального useState.
Если у вас есть конкретные примеры из вашей практики коммерческой разработки, я прошу вас поделиться со всеми.
В документации вы не найдете пять этих разных способов. Приведу вам пример из собственного кода. Вот создание экшна для глобального модала через слайс, который объединяет все экшны и редюсеры.
А вот как он используется в компоненте.
openModal может быть напрямую импортирован из файла слайса. Все. Никаких пяти методов.
То, что вы перечислили – это API Redux образца 2018 года. Если вы взглянете на документацию Redux Toolkit, то ничего из перечисленного вы не увидите. Я лично использую Redux Toolkit уже пять лет на работе и в личных проектах. Очень рекомендую взглянуть.
Богатый выбор. Возможно, есть компании, в которых каждый разработчик выбирает свой способ и пишет, как ему нравится. Я желаю им удачи.
Моя статья посвящена скоростной разработке масштабируемого MVP для веб-стартапа. Мне был нужен один эффективный, быстрый и предсказуемый способ работы со state, и мой выбор за Redux Toolkit.
Вы знаете, я не специалист по kr-observable, и не рассматриваю его в данной статье. Если для вас интересны бенчмарки, то давайте посмотрим на картинку еще раз. First paint – mobx 272.4, react redux hooks - 208.7. React redux immutable 285. Какие выводы, которые имеют значение на практике, вы можете сделать из этих данных? Сталкивались ли вы конкретно в своей практике со случаями низкой производительности Redux?
Что касается экшенов.
Благодарю вас за объяснение, но из документации непонятно, почему в этой табличке шесть вкладок. Как разработчик, я не хочу тратить большое количество времени на чтение документации, и потом узнавать на Хабре, что на самом деле только три вкладки означают варианты экшн диспатча. Как разработчик, я хочу один предсказуемый способ отправки экшна, о котором я могу рассказать других разработчикам. Я не хочу спорить с другими разработчиками, которые сделали это другим способом, потому что он тоже есть документации, что предсказуемость и читаемость кода важнее, чем то, что вам захотелось это сделать способом номер 2, потому что вам показалось это круче или вы написали на одну строчку кода меньше.
Redux в 2018 году и Redux Toolkit в 2025 это две большие разницы, я очень рекомендую взглянуть на документацию Redux Toolkit. За эти семь лет я работал в различных стартапах и корпорациях, где почти повсеместно использовался Redux, без каких-либо проблем и трудностей. В том числе в сферах, где производительность важна – в корпоративном мессенджере, например. Если вы сталкивались с проблемами с производительностью в Redux – прошу вас поделиться опытом.
За экшн криэйторы мне уже выше пояснили – да, я неправильно применил термин, потому что большую часть времени работаю с Redux. Сути, однако, это не меняет – зачем нужно шесть вариантов одного и того же действия, никто не объясняет. Мне, как разработчику и человеку, который обучает других разработчиков, в первую очередь важна простота использования, расширения, рефакторинга при применении библиотеки, и меньше возможности накосячить. Если что-то может быть достигнуто, то я предпочитаю один предсказуемый путь, который я могу написать с закрытыми глазами, а не шесть, и потом не спорить с разработчиками о том, почему это сделано способом номер 3, а не номер 5, которые все есть в документации.
Я работаю с Redux семь лет, и ни разу не сталкивался с проблемами с производительностью в нем. Больше того, я привел пример с огромными геоджейсонами, которые не влияли на производительность никоим образом. Если вы сталкивались, прошу привести конкретные примеры ваших юзкейсов. В статье, которую вы приводите, в частности, потребление памяти – у всех плюс минус одно и то же.
В частности, в вашем примере mobx в некоторых кейсах по потреблению памяти проигрывает.
Дополнительно посмотрел сайт mobx, и сейчас диспатчить экшены можно шестью разными способами: https://mobx.js.org/actions.html. В чем разница, и зачем нужно шесть вариантов, конкретно на этой странице не объясняется.
В своей практике я также использовал принцип «бурения», последовательного задавания уточняющих вопросов, так можно поймать не только начинающих, но и в принципе людей, преувеличивающих свое участие в проекте, вне зависимости от синьорности. Интервьюеры часто идут по верхам, потому что лень придумывать вопросы на лету, и этим пользуются.
Непосредственно волшебные слова, о которых вы говорите, были созданы для одной задачи – продаж консультационных услуг большим корпоративным заказчикам в США. Вся методология рассчитана на то, чтобы выставить счет клиенту за короткий срок (по спринтам) и получить деньги, пока большой заказчик не передумал делать проект вообще или не выкинул консультантов на мороз, увидев финальный результат.
За отсутствием адекватной альтернативы, аджайл / канбан стал мейнстримом и общественная дискуссия о его адекватности стихла. Я бы хотел эту дискуссию оживить, потому что эта методология оказывает большое влияние не только на ежедневные рабочие процессы и качество результата, но и на психологию работы.
Однозначно соглашусь с вами по поводу основной задачи – поиска подходящих кадров. Проблема аджайла / канбана в том, что неподходящим людям в корпоративной среде аджайл благоволит за счет возможности имитации бурной деятельности путем инфляции оценок, создания бесконечного количества тикетов. Некомпетентность может прятаться в бюрократии. Поэтому вместо аджайла необходим метод, который позволит эффективно вскрывать таких людей (фигурально выражаясь). Это является одной из важнейших задач итеративно-функционального метода.
bodyshop – это распространенное в англоязычной сфере наименование аутстаффинговых агентств, которые сдают в аренду своих разработчиков на проекты заказчиков. Я почему-то думал, что в русскоязычной сфере это слово тоже в ходу.
Я бы сказал, что я выравниваю баланс, потому что на Хабре критики аджайла и канбана как такового немного. Разумеется, слишком часто публиковать статьи подобного рода я не собираюсь.
Про абсолютно ничего не предлагается взамен – ну, это перевод статьи 2015 года, и автор не был в курсе, что в 2024 году появится итеративно-функциональный метод, созданный на замену agile и kanban практикам. В начале статьи есть указание, что перевод подготовлен редакцией итеративно-функционального метода, а также есть гиперссылка на сайт проекта. Вот конкретно этот метод, не имеющий с аджайлом ничего общего кроме итеративности (что не есть изобретение аджилистов), я и предлагаю взамен.
Также отмечу, что критики аджайла не так много в том числе потому, что критики не могут ничего сказать на довод аджилистов "А что вы предлагаете взамен?". Теперь ответ есть.
Вселенная Москвы 2055 весьма консервативна в плане прогресса, прорывов в плане космических путешествий не случилось, но есть очень серьезные подвижки в лечении почти всех болезней и в нейроинтерфейсах.
Я соглашусь, что статья эмоциональная и автор опирается только на собственный опыт. Перевел я ее скорее потому, что некоторые недостатки Agile / Scrum подсвечены ярко, в частности, вымывание ценных кадров. Кадры решают все. У вас был нормальный тех. руководитель и я рад за вас. Нам нужна методология, которую как минимум плохие менеджеры не смогут эксплуатировать в своих интересах, как аджайл, а как максимум – поможет сделать наглядной некомпетентность менеджеров и исполнителей, если таковая имеет место быть.
Интересны причины, по которым участники застревали на задачах на месяц. Мне кажется, именно смещение акцента на раннее выявление рисков такого развития событий могут улучшить производительность команды, чем трата времени на аджайл покер с 3 - 5 - 8 стори-поинтами и соответственное переписывание user stories. Больше того, я бы скорее дал разработчикам несколько дней поработать непосредственно над фичей и ее низкоуровневой архитектурой, а уже потом разговаривал с ними о возможных дедлайнах.
да, action creator, а что он еще должен делать кроме передачи данных? Изменением state занимается reducer.
Я немного перепутал с api файлом, у меня есть еще кастомный хук, в котором я держу инфраструктуру Redux Toolkit по модалам.
Я создал его один раз и использую по всему коду. Равно как и глобальный стор я создаю один раз и при создании нового слайса просто добавляю две строчки к глобальному стору.
Вы видите остальные 4 способа в документации Redux Toolkit? Допустим, если я не работал с этой библиотекой, я открываю документацию и вижу один способ. Зачем мне выбирать из 4 способов, о которых я не знаю и о которых там не пишут?
давайте опустим kr-observable, если вы не против. Как я говорил, я не специалист в этой библиотеке.
Если вы сталкивались со случаями низкой производительности Redux, прошу Вас поделиться опытом, что за тип приложения вы разрабатывали, как именно проявлялась деградация производительности, что вы предпринимали для того, чтобы понять корневую причину проблемы? Для сообщества Хабра это было бы ценной информацией.
В ваших примерах со счетчиками – Redux Toolkit имеет несколько дополнительных строк кода по сравнению с Mobx. Это нормально. Во-первых, количество строк кода не равно простоте его поддерживания. Вы можете написать совершенно кривой и неподдерживаемый код на 10 строках, и иметь простой и ясный код на 15 строках.
Больше того, примеры со счетчиками я не считаю корректными в принципе, потому что они не имеют тех проблем, которые имеют коммерческие продукты. Несколько человек не работают над счетчиками одновременно, счетчики не содержат сложной оркестрации HTTPS запросов, их данные не должны переиспользоваться в разных местах. Счетчикам в принципе не нужен state management, им достаточно локального useState.
Если у вас есть конкретные примеры из вашей практики коммерческой разработки, я прошу вас поделиться со всеми.
В документации вы не найдете пять этих разных способов. Приведу вам пример из собственного кода. Вот создание экшна для глобального модала через слайс, который объединяет все экшны и редюсеры.
А вот как он используется в компоненте.
openModal может быть напрямую импортирован из файла слайса. Все. Никаких пяти методов.
То, что вы перечислили – это API Redux образца 2018 года. Если вы взглянете на документацию Redux Toolkit, то ничего из перечисленного вы не увидите. Я лично использую Redux Toolkit уже пять лет на работе и в личных проектах. Очень рекомендую взглянуть.
Богатый выбор. Возможно, есть компании, в которых каждый разработчик выбирает свой способ и пишет, как ему нравится. Я желаю им удачи.
Моя статья посвящена скоростной разработке масштабируемого MVP для веб-стартапа. Мне был нужен один эффективный, быстрый и предсказуемый способ работы со state, и мой выбор за Redux Toolkit.
Вы знаете, я не специалист по kr-observable, и не рассматриваю его в данной статье. Если для вас интересны бенчмарки, то давайте посмотрим на картинку еще раз. First paint – mobx 272.4, react redux hooks - 208.7. React redux immutable 285. Какие выводы, которые имеют значение на практике, вы можете сделать из этих данных? Сталкивались ли вы конкретно в своей практике со случаями низкой производительности Redux?
Что касается экшенов.
Благодарю вас за объяснение, но из документации непонятно, почему в этой табличке шесть вкладок. Как разработчик, я не хочу тратить большое количество времени на чтение документации, и потом узнавать на Хабре, что на самом деле только три вкладки означают варианты экшн диспатча. Как разработчик, я хочу один предсказуемый способ отправки экшна, о котором я могу рассказать других разработчикам. Я не хочу спорить с другими разработчиками, которые сделали это другим способом, потому что он тоже есть документации, что предсказуемость и читаемость кода важнее, чем то, что вам захотелось это сделать способом номер 2, потому что вам показалось это круче или вы написали на одну строчку кода меньше.
Redux в 2018 году и Redux Toolkit в 2025 это две большие разницы, я очень рекомендую взглянуть на документацию Redux Toolkit. За эти семь лет я работал в различных стартапах и корпорациях, где почти повсеместно использовался Redux, без каких-либо проблем и трудностей. В том числе в сферах, где производительность важна – в корпоративном мессенджере, например. Если вы сталкивались с проблемами с производительностью в Redux – прошу вас поделиться опытом.
За экшн криэйторы мне уже выше пояснили – да, я неправильно применил термин, потому что большую часть времени работаю с Redux. Сути, однако, это не меняет – зачем нужно шесть вариантов одного и того же действия, никто не объясняет. Мне, как разработчику и человеку, который обучает других разработчиков, в первую очередь важна простота использования, расширения, рефакторинга при применении библиотеки, и меньше возможности накосячить. Если что-то может быть достигнуто, то я предпочитаю один предсказуемый путь, который я могу написать с закрытыми глазами, а не шесть, и потом не спорить с разработчиками о том, почему это сделано способом номер 3, а не номер 5, которые все есть в документации.
Я работаю с Redux семь лет, и ни разу не сталкивался с проблемами с производительностью в нем. Больше того, я привел пример с огромными геоджейсонами, которые не влияли на производительность никоим образом. Если вы сталкивались, прошу привести конкретные примеры ваших юзкейсов. В статье, которую вы приводите, в частности, потребление памяти – у всех плюс минус одно и то же.
В частности, в вашем примере mobx в некоторых кейсах по потреблению памяти проигрывает.
Дополнительно посмотрел сайт mobx, и сейчас диспатчить экшены можно шестью разными способами: https://mobx.js.org/actions.html. В чем разница, и зачем нужно шесть вариантов, конкретно на этой странице не объясняется.
это больше похоже на вейп-кодинг..
А разве это не везде так?
В своей практике я также использовал принцип «бурения», последовательного задавания уточняющих вопросов, так можно поймать не только начинающих, но и в принципе людей, преувеличивающих свое участие в проекте, вне зависимости от синьорности. Интервьюеры часто идут по верхам, потому что лень придумывать вопросы на лету, и этим пользуются.
Непосредственно волшебные слова, о которых вы говорите, были созданы для одной задачи – продаж консультационных услуг большим корпоративным заказчикам в США. Вся методология рассчитана на то, чтобы выставить счет клиенту за короткий срок (по спринтам) и получить деньги, пока большой заказчик не передумал делать проект вообще или не выкинул консультантов на мороз, увидев финальный результат.
За отсутствием адекватной альтернативы, аджайл / канбан стал мейнстримом и общественная дискуссия о его адекватности стихла. Я бы хотел эту дискуссию оживить, потому что эта методология оказывает большое влияние не только на ежедневные рабочие процессы и качество результата, но и на психологию работы.
Однозначно соглашусь с вами по поводу основной задачи – поиска подходящих кадров. Проблема аджайла / канбана в том, что неподходящим людям в корпоративной среде аджайл благоволит за счет возможности имитации бурной деятельности путем инфляции оценок, создания бесконечного количества тикетов. Некомпетентность может прятаться в бюрократии. Поэтому вместо аджайла необходим метод, который позволит эффективно вскрывать таких людей (фигурально выражаясь). Это является одной из важнейших задач итеративно-функционального метода.
bodyshop – это распространенное в англоязычной сфере наименование аутстаффинговых агентств, которые сдают в аренду своих разработчиков на проекты заказчиков. Я почему-то думал, что в русскоязычной сфере это слово тоже в ходу.
Я бы сказал, что я выравниваю баланс, потому что на Хабре критики аджайла и канбана как такового немного. Разумеется, слишком часто публиковать статьи подобного рода я не собираюсь.
Про абсолютно ничего не предлагается взамен – ну, это перевод статьи 2015 года, и автор не был в курсе, что в 2024 году появится итеративно-функциональный метод, созданный на замену agile и kanban практикам. В начале статьи есть указание, что перевод подготовлен редакцией итеративно-функционального метода, а также есть гиперссылка на сайт проекта. Вот конкретно этот метод, не имеющий с аджайлом ничего общего кроме итеративности (что не есть изобретение аджилистов), я и предлагаю взамен.
Также отмечу, что критики аджайла не так много в том числе потому, что критики не могут ничего сказать на довод аджилистов "А что вы предлагаете взамен?". Теперь ответ есть.
Благодарю! Эти вопросы я уточню.
Вселенная Москвы 2055 весьма консервативна в плане прогресса, прорывов в плане космических путешествий не случилось, но есть очень серьезные подвижки в лечении почти всех болезней и в нейроинтерфейсах.
Я соглашусь, что статья эмоциональная и автор опирается только на собственный опыт. Перевел я ее скорее потому, что некоторые недостатки Agile / Scrum подсвечены ярко, в частности, вымывание ценных кадров. Кадры решают все. У вас был нормальный тех. руководитель и я рад за вас. Нам нужна методология, которую как минимум плохие менеджеры не смогут эксплуатировать в своих интересах, как аджайл, а как максимум – поможет сделать наглядной некомпетентность менеджеров и исполнителей, если таковая имеет место быть.
Интересны причины, по которым участники застревали на задачах на месяц. Мне кажется, именно смещение акцента на раннее выявление рисков такого развития событий могут улучшить производительность команды, чем трата времени на аджайл покер с 3 - 5 - 8 стори-поинтами и соответственное переписывание user stories. Больше того, я бы скорее дал разработчикам несколько дней поработать непосредственно над фичей и ее низкоуровневой архитектурой, а уже потом разговаривал с ними о возможных дедлайнах.
это ваша авторская методология?