I guess, it can be implemented in the same way scopes work 🤔

let pureContext = false
const runPure = (cb, ...args) => {
 pureContext = true
 cb(...args)
 pureContext = false
} 

...
// somewhere in `launch`
if (pureContext) {
 throw Error(...)
}

Should we really add this to core package? I think it can be implemented through effector/eslint-plugin

Should we really add this to core package? I think it can be implemented through effector/eslint-plugin

Sure, it can (and, i guess, should) be implemented as eslint-plugin rule too, but it won't be as reliable as actual check at the core + not all projects using this eslint-plugin

So, i think, it is better if plain-wrong practices like in the example are prevented at the core level

There may be some edge cases as event calls may be deeply reordered before execution, not even mention events called from watchers during execution of the forbidden event call, so runtime error may appear in entirely irrelevant places of code
And avoiding that issue would introduce another full-featured call stack with complex logic to manage it

I would rather prefer an eslint rule

@zerobias What about to add some extra parameter to a compute

And in the appropriate switch/case check it only if parameter is true? Computations already has isWatch flag, why not add isReducer flag?

it could shoot me in the foot?

@sergeysova well, looks like it should work in that way, let's try 👌

Deprecation warning will be published in the next minor release

Proposal

Throw error or show a console warning, if event or effect have been manually called from inside of store reducer or other pure functions.

Currently effector does not forbid or warn about event or effect calls inside reducers or other supposed-to-be-pure functions like fn of sample or combine rule

But, as it can be seen at effector telegram chat, many people do call events from reducers sometimes (and sometimes for a really long time) and have no clue, that it is not how it supposed to work.

Even though effector, apparently, still can handle that, using events this way goes way too much aganist declared rules and some projects may found themselves absolutely incompatible with some future release of effector

I think, explicit warning (or even exception) like

effector events must not be called from pure functions like store reducers or fn of sample.
Use effector operators instead.
Or, if you really need imperative control flow, use watch or effect for that

will help a lot here

Use case

Today an effector user shared the way he has been using .on for a long time - it was something like this:

// this code must be either rewritten to operators or written in the same way, but inside `.watch`
$store.on(someEvent, (state, payload) => { 
 // store reducer meant to update stored value
 if (payload.some) {
   // but there is some control flow happening instead, which is wrong
   someEffect(state)
 } else {
  someOtherEvent(payload)
 }
 // next state is never returned - plain wrong usage of `.on`
})

From his words, he was using effector like that from the very beginning and have not seen any problems yet.

Obviously, all of it mentioned in the documentation, but it looks like that sometimes people do not read it carefully enough and little push is needed

But what if I want to create an effect which triggers 2 effects which are expected to be done together?

const effect = createEffect(() => Promise.all([fx1, fx2]))

If we write this way we get the warning in console as well

There should be no warning in your case, it’s valid usage