С async/await асинхронный код выглядит, как обычный синхронный код. Это позволяет записать больше логики в одном методе, но также кроет в себе опасность, особенно для начинающих разработчиков. Из-за этого они плохо понимают, как работает асинхронность, и просто ставят async/await везде, где только можно.
На самом деле, код после await, выполняется в другой момент времени и должен выносится в отдельный метод, подобно обработчикам событий. Это избавляет от хеллов и лучше с точки зрения разделения кода.
Меня всё-равно смущает, что сброс страницы привязывается именно к обновлению вильтров. Если бы эти сущности были настолько связаны, то их следовало бы делать в одной модели. Можно передать <Filters onChange={updateFiltersAndResetPage} filter={filters}/> и не будет проблем.)
Изначально вопрос был об обновлении одних данных, при изменении других. Пример с фильтром не я привёл, наверное он действительно не очень удачный. Но если мы делаем автообновление, то оно будет срабатывать всегда, даже если это не нужно. Поэтому лучше всегда делать атомарные экшены, а если какие-то повторяются чаще, то можно сделать дополнительные экшены, которые будут объединять несколько. Так не потеряется гибкость. Я уже приводил примеры выше.
Ну да, если действие слишком частое, можно сделать дополнительный экшен setFilterAndPage({filter, page}).
Это намного лучше, чем сначала сделать автоматический сброс страницы, а потом появится кейс, где нужно поменять фильтр, а страница не должна сбрасываться.
С
async/awaitасинхронный код выглядит, как обычный синхронный код. Это позволяет записать больше логики в одном методе, но также кроет в себе опасность, особенно для начинающих разработчиков. Из-за этого они плохо понимают, как работает асинхронность, и просто ставятasync/awaitвезде, где только можно.На самом деле, код после
await, выполняется в другой момент времени и должен выносится в отдельный метод, подобно обработчикам событий. Это избавляет от хеллов и лучше с точки зрения разделения кода.У меня есть видео-урок по асинхронности, там более подробно об этом рассказано: https://youtu.be/p0d8p9C2aYs
Использую webpack-merge: https://github.com/SuhushinAS/react-starter-kit/blob/master/webpack.config.js
Какое решение предлагаете вы?
Названия же не обязательно именно такими делать, верно?
Меня всё-равно смущает, что сброс страницы привязывается именно к обновлению вильтров. Если бы эти сущности были настолько связаны, то их следовало бы делать в одной модели. Можно передать
<Filters onChange={updateFiltersAndResetPage} filter={filters}/>и не будет проблем.)Возможно. Плохо, когда технические детали влияют на логику работы.
Изначально вопрос был об обновлении одних данных, при изменении других. Пример с фильтром не я привёл, наверное он действительно не очень удачный. Но если мы делаем автообновление, то оно будет срабатывать всегда, даже если это не нужно. Поэтому лучше всегда делать атомарные экшены, а если какие-то повторяются чаще, то можно сделать дополнительные экшены, которые будут объединять несколько. Так не потеряется гибкость. Я уже приводил примеры выше.
Нужно сделать экшен, который будет объединять несколько других экшенов. Я уже привёл пример выше. В чём здесь проблема?
Редакс - это хранилище данных, в его задачи не входит автообновление.
Ну да, если действие слишком частое, можно сделать дополнительный экшен
setFilterAndPage({filter, page}).Это намного лучше, чем сначала сделать автоматический сброс страницы, а потом появится кейс, где нужно поменять фильтр, а страница не должна сбрасываться.
Мне кажется, создание автоматических триггеров смены одних данных от других, как раз и вызывает запутанность кода.
Сделайте 2 простых экшена:
setFilter(filter)иsetPage(page), а в форме фильтров наonSubmitвызывайте оба.Я оформил чеклист приёмки макетов, перед взятием их в работу.
https://github.com/SuhushinAS/design-checklist
Может кому-нибудь будет полезно.