яннп

С совой согласен полностью

Эффект символизирует асинхронную функцию, которую можно вызывать, и ключевое здесь то, что никакого наблюдаемого состояния у неё нет принципиально, ты просто не имеешь возможности увидеть то, как и где сохраняется состояние после её вызова, для тебя есть лишь отдельные события init, done и fail, которые — вот совпадение — выглядят так будто реализуют длительный асинхронный вызов функции.

Эффекты нужны для того, чтобы завершение асинхронной функции стало статически наблюдаемым, то есть, чтобы была возможность подписаться на завершения и ошибки вызова данных эффектов

Сторы имеют с эффектами только одно общее — происхождение. Они банально построены из одних и тех же материалов — эвентов, но примешивают к ним радикально разное поведение

К вопросу "зачем разделять" — затем,  что объединение сущностей усложняет принципы, а разделение — упрощает, так как вместо одной сущности со сложным поведением имеем две простых, имеющих много общего

Отсюда же и шаблонные названия методов-конструкторов. Можно свалить все create* в один огромный гипер-полиморфный метод (привет, react-redux) но его использование будет сопряжено со значительными трудностями во всех отношениях

Хочу отметить, что не хотелось бы скатываться в догматизм, библиотека сделана таким образом, что базовые её публичные элементы (события) реализуют максимально узкий набор операций,  чтобы можно было делать более сложные сущности просто на их основе

Пример: эффект, изначально, — это тупо эвент, к которому дописано два других

function createEffect() {
  const init = createEvent('init')
  init.done = createEvent('done')
  init.fail = createEvent('fail')
  
  let thunk = async (arg) => {}
  init.use = (newThunk) => {thunk = newThunk}
  
  init.watch(arg => thunk(arg).then(done, fail))

  return init
}

То бишь, предполагается изначально, что на основе базовых элементов будут делать свои собственные, чтобы можно было уже наконец перейти от бесконечных гипотез к конкретным реализациям

Считаешь что сторы имеют фатальный ™️ недостаток? Запили proof of conept своих собственных, максимально прямолинейно, так же как прямолинейно реализованы эффекты выше — все будут только рады если концепция окажется ещё лучше чем было

function createEffect() {
  const init = createEvent('init')
  init.done = createEvent('done')
  init.fail = createEvent('fail')
  
  let thunk = async (arg) => {}
  init.use = (newThunk) => {thunk = newThunk}
  
  init.watch(arg => thunk(arg).then(done, fail))

  return init
}

А ты задумывался как обеспечить нормальную работу эффектов, которые вызываются по нескольку раз?

В эффекторе нет проблемы this, всё по дефолту свободно переназначается, например, так что можно пробовать разные подходы

В плане?

К примеру эффект - это получение данных с сервера по нажатию на кнопку "загрузить" в списке. Пользователь быстро нажал на 3 кнопки. В идеале хотелось бы отменить 2 старых запроса.

Как-то так список с эффектами на загрузку выглядит.

Но я понял, что надо пилить свой эффект по аналогии с тем, что ты написал выше.

А что должны получить те кто ожидает результатов выполнения старых запросов?

Их нет.

Тогда проблем нет)

Я, наоборот, пытаюсь унифицировать, а не создать "мастер" сущность