Custom classes & tweaking issues

[maccman]

Hello @xaviergonz,

While we absolutely love keystone (thanks again!) we are trying to reduce usage of it in place where we are running into memory constraints on mobile. We find that adding keystone to a class doubles the size of that object in v8 over a plain mobx class (i.e. a class using makeObservable). And we find that mobx classes are three times as big as a plain class. So we want to move to plain classes as much as possible whenever we are running into perf bottlenecks.

By passing in a plain class to keystone we get the Error: Error: tweak can only work over models, observable objects/arrays, or primitives, but got [object Object] instead.

I'm wondering if you support this kind of thing? Ideally we'd define a few functions that instruct keystone how to serialize/deserialize the class from json, and then keystone would assume that we'd handle reactivity etc for that class.

[xaviergonz]

Does that class need to be serializable (fromSnapshot/getSnapshot support) or support for JSON patches and so on?

Where I'm heading is that if that class is UI related rather than document related then maybe it doesn't need those capabilities and so it could be a mobx / plain class to save memory. If it is a document related model then probably it already needs all that and there's no way around it.

Usually the pattern I find the best is having the "document model" exclusively made with mobx-keystone (and that way it is easier to serialize via fromSnapshot/getSnapshot) so it is not polluted with UI stuff, and then there's a UI model (probably made with mobx classes) that occasionally point model(s) within the document model.

Also, an alternative that probably can be made without any changes to mobx-keystone is making your custom plain class "wrap around" a frozen value in the tree and make it so whenever something in your custom class changes then it will regenerate a plain JSON-compatible value that replaces the old frozen value. That way you get the custom class and the value is still useable by mobx-keystone.

Assuming it is a document model (the architecture change doesn't solve your problem), or the frozen "trick" is not good enough, what you are asking is kind of like a "custom model" right? In order for it to fit into mobx-keystone it would need to support:

• A way to serialize/deserialize it to/from a JSON like object (like you pointed out)
• A way to inform mobx-keystone whenever its snapshot has changed (via the JSON patches on how it actually changed)

Do you think you'd be able to provide those from your custom model? (and if it's worth the effort)

[vojto]

I also noticed that memory usage explodes when array property is used. In my testing that's 3kB per property. (Mobx seems to be using about 0.6kB per array property.)

[maccman]

@xaviergonz just wonder if you saw @vojto's message

[maccman]

Also is it possible to release your latest changes? We'll upgrade and let you know how it goes.

[xaviergonz]

With the latest version I just released, 1.4.0, which includes some optimizations, with 2000 instances of 1 property the tests shows this:

[1 props, 2000 instances]

# simple props
mobxObj: 2,662,456B (1,332B/each)
mobxMap: 2,452,616B (1,227B/each)
mobxKeystoneClass instance creation (prop): 7,268,760B (3,635B/each)
mobxKeystoneClass instance creation (tProp): 7,955,200B (3,978B/each)

# array props
mobxObj: 3,843,864B (1,922B/each)
mobxMap: 3,970,464B (1,986B/each)
mobxKeystoneClass instance creation (prop): 15,214,000B (7,607B/each)
mobxKeystoneClass instance creation (tProp): 16,960,560B (8,481B/each)

# object props
mobxObj: 4,273,024B (2,137B/each)
mobxMap: 4,003,432B (2,002B/each)
mobxKeystoneClass instance creation (prop): 15,090,832B (7,546B/each)
mobxKeystoneClass instance creation (tProp): 17,086,048B (8,544B/each)

The increase in size is expected since mobx-keystone actually does more stuff under the hood than plain mobx (e.g. keep track of the object parents, interceptors and observers, validators (in the case of tProps, etc.)

Note that the new version needs Proxy support.

[maccman]

Great! In our test this seems to have reduced note size from 90kB to 80kB. 11% savings! Thank you.