Best way to implement inheritance for mst-gql-like payload normalizer (merge function) #2955
Unanswered
techknowfile
asked this question in
Q&A
Replies: 1 comment
-
There was recently a similar (?) issue, which you might want to check out #2951 Not sure why the superclass is needed? Why that logic must be part of a constructor or why |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm moving away from mst and mst-gql due to memory issues. However, I am very fond of the normalized RootStore data structure, and the automatic "merge" function that can populate the data structure with API data.
As such, I've replicated the functionality of this function in my own RootStore implementation, which I've included at the bottom of this post for completeness.
The issue I'm facing is that in order to get all of my "MobX items" to function properly with this merge function, I have them all extend a SuperClass called MobXObject. As you can see from the constructor below, this is what enables the creation of arbitrary attributes on a javascript object given some JSON:
But by using this approach, I'm not able to use the
makeAutoObservable
function, because that can't be used on classes with superclasses. It seems mobx-state-tree uses a builder-pattern approach (please let me know if there is a more accurate name for this pattern) that allows javascript prototypes to inherit functions without having to worry about class-based inheritance.Merge function:
This allows me to instantiate a RootStore with the following, where the constructor of the RootStore uses the passed object basically in place of the configureStoreMixin from mst-gql
Beta Was this translation helpful? Give feedback.
All reactions