A slightly strange idea: Statically defined watch and getState

[AlexandrHoroshih]

Now in the effector you can "look at" any part of the computational graph of the application from any part of it:

const unwatch = $products.watch(list => ...) // now i'm watching

unwatch() // now i'm not

$products.getState()

This seems to be the only completely dynamic part of the computational graph that remains in the library's api

What about to make it statically defined too? (in the far future, obviously)

[AlexandrHoroshih]

This way we could say, just by looking at computational graph and before any actual computations, which parts of the app may have observable side-effects and which are not:
If some part of apps logic is never produces any side-effects like web-requests or ui-rendering, then it is, in fact, useless - we can remove this code and there will be no observable difference.

If we could statically detect such parts of the app, then it would be possible e.g. to highlight such parts of the app in The DevTools as "unused", which is may be useful for large apps in active development

And maybe even some other benefits or performance optimizations:
like detecting such "dead" parts of the app in the runtime and suspend them until there is a side-effect or non-derived store (since they must not miss any updates, they cannot be turned off and so are all of their sources of updates)

Currently, because watch and getState are exist on every store and event - there is no way to do something like this, since from effector's point of view .getState can happen at any moment anywhere

But if the effector won't let users to watch stores directly, but e.g. only through special, statically defined units, then this dynamic may become more predictable 🤔

Not sure, if it is a dumb idea or not 🤷‍♂️

[AlexandrHoroshih]

I guess, the API could look something like this 🤔

const productsWatcher = createWatcher({
 source: $products
})

productsWatcher.getState()
const unwatch = productsWatcher.watch(list => ...)

// e.g. react integration
// view-model.ts
export const modelWatcher = createWatcher({
 source: { a: $a, b: $b, c: $c }
})
// ui.tsx
const { a, b, c} = useWatcher(modelWatcher)

// e.g. tests
const eventWatcher = createWatcher({
 source: myEvent
})
eventWatcher.watch(jestMockToTrackThisEvent)

[zerobias]

Watchers usually should be added to scope, so it would looks like that:

const testingScope = fork({
  watch: [{
    trigger: myEvent,
    fn: jestMockToTrackThisEvent,
  }]
})

[zerobias]

To make this suggestion works, eventWatcher must be declared in .babelrc because there is no way to detect whether that import is watcher or not, thereby making eventWatcher a common factory.
Which essentially turns this idea to factory option:

["effector/babel-plugin", {
  "factories": [
    {
      "path": "testUtils/eventWatcher",
      "sideEffects": true
    }
  ]
}]