Rule: `no-fx-direct-call`
// 👍
const myFx = createEffect();
const evt = createEvent();
forward({
from: createEvent,
to: myFx
})
await allSettled(myFx, { scope })
const anotherFx = createEffect(async () => {
await myFx()
})
// 👎
const myFx = createEffect();
myFx()
Could you describe your idea, please?
In my opinion, this case should be covered by https://github.com/effector/eslint-plugin/issues/30
In my opinion calling the effect directly gives less control over its calls. By calling with events we have the possibility to describe the conditions for calling the effect explicitly and not smeared in the application.
For example:
const evt = createEvent();
const someFx = createEffect();
// today
forward({
from: evt,
to: someFx
});
// maybe tomorrow, without changing whole app
sample({
clock: guard({
clock: evt,
source: someFx.pending,
filter: (isPending) => !isPending
}),
source: evt,
target: someFx
});
OK, I see.
Let me think about it a couple of times. And maybe someone from @effector/core will provide their opinion of this topic.
What about
const someFx = createEffect();
const evt = someFx.prepend()
What about effect calls inside other effects? It is allowed and perfectly valid, if only effects are awaited
const controllerFx = createEffect(async () => {
const result = await oneFx()
return await twoFx(result)
})
const publishReleaseFx = createEffect(async () => {
await authUserFx()
await pushCommitFx()
await buildCommitFx()
await pushBuildFx()
})
Maybe, even separate rule is needed for that 🤔
This feature, usually, not very useful for main logic of the app, but is very handy, when creating operators like this or other specific edge-cases
@AlexandrHoroshih I propose "Effects called inside another effect should not be warned."
Cause I can await it soon:
const publishReleaseFx = createEffect(async () => {
await Promise.all([
authUserFx(),
pushCommitFx(),
buildCommitFx(),
pushBuildFx(),
])
})