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

А есть пример?

Я бы написал, но не у компа

Тебе надо через хук домена на создание стора добавить каждому стору ресет на анмаунт гейта

upd. соре, я глубже юзал не стор

О. Ништяк. Спасибо.

а функции в эвенты передавать плохая практика?

Случайно не от final form?

не

А что дальше с функциями этими настроен делать?

permissions: updatePermission(user.permissions)  в сторе

forward({
  from: grantPermission.map(({ employeeId, permission }) => ({
    employeeId,
    // eslint-disable-next-line no-bitwise
    updatePermissions: (permissions) => permissions | permission,
  })),
  to: changeEmployeePermissions,
})

Выглядит как оверхед. Можно чуть больше контекста и задачу?

нужно обновлять права в массиве пользователей

.on(changeEmployeePermissions, (users, { employeeId, updatePermission }) => {
    const index = users.findIndex((user) => user.id === employeeId)

    if (index !== -1) {
      const user = users[index]

      users.splice(index, 1, { ...users[index], permissions: updatePermission(user.permissions) })
    }

    return users
  })

и есть эвенты которые меняют права:
permissions | permission,
или
permissions & ~permission

и чтобы не дублировать
const index = users.findIndex((user) => user.id === employeeId) …
хочется на уровень выше сделать

А почему это представление не должно знать про контроллер/модели? Представление очень часто является источником фичи и всей бизнес-логики - дизайнер/заказчик определяет - вот тут надо добавить кнопку которая делает то и то. У нас тут прямая связь представления (кнопки со стилями) с логикой. Нет кнопки - нет всей этой логики. Если мы начнем разделять и добавлять косвенности (мол все что должна знать кнопка так это вызов события который будет обрабатываться где-то в другом месте) то получим что добавленный код в коммите новой фичи будет ровным слоем размазан на кучу файлов вместо того чтобы быть в одном месте рядом с самой кнопкой.
И если потребуется удалить кнопку или изменить то что она делает то придется потом пройтись и удалить/поменять код во всех этих файлах/местах (вместо того чтобы удалить его одни куском вместе с кнопкой когда вся логика будет записана внутри onClick-обработчика на кнопке).
Ну и плюс намного удобнее читать код и понимать что происходит когда все что делает кнопка будет записано внутри обработчика и не нужно прыгать по куче файлов и вручную собирать картину в голове какие события вызывает кнопка и как на нее реагируют различные части приложения
В итоге наворачивать все эти слои косвенности имеет смысл только тогда когда мы начинаем дублировать код. Например, если несколько кнопок должны выполнить одну и ту же логику то тогда действительно нужно вынести логику в функцию чтобы ее не дублировать в каждом обработчике

Тогда это не MVC

и у тебя вся вьюха засрата обработчиками БЛа?

а если логика повторяется?

а что если у тебя целая операция триггерится по клику этому

состоящая из кучи других сабтасков