Pattern of lifecycle implementation

[techknowfile]

I'm having to move away from mobx-state-tree to pure mobx due to the huge memory footprint imposed when using mobx-state-tree.

However, there are many features of mobx-state-tree that I really like, or that I find downright necessary. I replicated mst-gql's merge() function, and now need an equivalent to afterAttach so that I can autorun() a function only once the necessary dependencies are available. This means that I need some sort of lifecycle manager that understands the concept of a tree when I'm merging the data into my MobX store (a normalized store similar to mst-gql structure).

I'm struggling to find details on how I might approach making such a mediator -- it looks like the general design pattern is some combination of a control and a mediator. I'm also not finding where in the mst source code these lifecycle methods get called.

Any assistance or examples would be greatly appreciated!

[jamonholmgren]

@techknowfile I'd like to know more about where you're encountering "huge memory footprint". Not because I don't believe you, but rather this would give us more of a place to focus to improve this.

In terms of where the afterAttach happens, here's the relevant bit of code (note that it's a bit indirect and doesn't call it directly).

mobx-state-tree/packages/mobx-state-tree/src/core/node/object-node.ts

Line 317 in 8ce9992

this.fireHook(Hook.afterAttach)