forwardRef operator or it's analog proposal
See original GitHub issueBecause of architecture of an Effector where all units and operations are written in top level of ES modules, and they start initialization in a moment when ES modules are imported you may often fall into trouble with circular dependencies and therefore broken build with “ReferenceError: Cannot access “$myStore” before initializaion” or even worst cases which sometimes very hard to debug and fix.
Proposal
The proposal is introducing a forwardRef
concept:
sample({
source: forwardRef(() => $myStore), // or simply define fn instead of references to other stores
target: '...'
})
The forward ref fn is called somewhere on later phase when all ES modules tree is already initialized (batch and flush on next micro task, or synchronously execute when very first event is dispatched).
I saw many suggestions and solutions how to structure the code to avoid this kind of error, many of them far from ideal and require an additional boilerplate. Sometimes even when everything structured in a right way you still have circular deps problem because of complicated structure of components and stores, wich really hard to follow and find where exactly problem come.
Issue Analytics
- State:
- Created a year ago
- Comments:26 (14 by maintainers)
Okay, then now we need to do a smoke test: is it enough to move to
defer
only links withtarget
?Let’s assume naive defer implementation (it will not be async in prod btw):
Please try to use it in your projects. Is it useful, did you avoided circular loops? Have you been able to use it in all the places where you would like to? Note that methods that create new units will have to be rewritten to an explicit unit creation and method with
target
If you want to create new unit you will not be able to use neither promises nor
domain.defer
anywaySo your code will looks like that