Accessing Referenced Data

[mashaalmemon]

Hi There,

I'm looking at mobx-keystone and mobx-state-tree as options for a normalized global store for a react app.

In mobx-state-tree they give an example here where a normalized reference can be accessed in a denormalized manner:

---- Mobx-State-Tree's example

const Todo = types.model({
    id: types.identifier,
    title: types.string
})

const TodoStore = types.model({
    todos: types.array(Todo),
    selectedTodo: types.reference(Todo)
})

// create a store with a normalized snapshot
const storeInstance = TodoStore.create({
    todos: [
        {
            id: "47",
            title: "Get coffee"
        }
    ],
    selectedTodo: "47"
})

// because `selectedTodo` is declared to be a reference, it returns the actual Todo node with the matching identifier
console.log(storeInstance.selectedTodo.title)
// prints "Get coffee"

With mobx-keystone I noticed that using a customRef you accessed the referenced item via the .current property of the ref. So as I understand it, if I build something similar to the above example with mobx-keystone to get the equivalent output I would instead have:

// Mobx-Keystone equivalent access

// because `selectedTodo` is declared to be a reference, it returns the reference which must be dereferenced using `curent`, to get the actual Todo node with the matching identifier
console.log(storeInstance.selectedTodo.current.title)
// prints "Get coffee"

However is there a way to access it the same way was you would in MST (accessing it and letting mobx-keystone do some magic and replace the reference with the actual object)?

[xaviergonz]

Hi there,

reference access are made explicit on purpose (kind of like useRef in react), this is, so the user has a clear notion that he's using a reference with all its pros an cons (e.g., that it will be valid only as long as the source (referenced node) is still there, etc).

For example, due to the accessor magic, in the case of MST, if you want to know if a reference is still valid you need to do a weird construct like:

isValid(() => storeInstance.selectedTodo)

because in the case the original selectedTodo no longer exists, then just doing storeInstance.selectedTodo will throw an error

in mobx-keystone you can do storeInstance.selectedTodo.maybeCurrent / storeInstance.selectedTodo.isValid instead

[mashaalmemon]

Thanks @xaviergonz for the explanation. I have a specific use case of the magic. Let me explain.

In my use case we have types already defined that are used in both our server side and client side that are denormalized. E.g.:

// these are not Mobx-Keystone models, but interfaces used for JSON data that is passed around our app

interface ITodoRecord {
  name:string;
  userResponsible: IUserRecord|null // denormalized
}

interface IUserRecord {
  firstName: string;
  lastName: string;
 // ... etc
}

What I was hoping to achieve was to use Mobx-keystone and have a denormalized store with models that essentially implement the same interface.

But to do this I need to have a little bit of that magic available. I'd also like the type coming out of the observable ObjectMap's I'm using to be ITodoRecord and IUserRecord so that the Mobx-keystone types are more of a Mobx specific detail then something the rest of the app on the client side needs to be aware of. I believe I have acheived this here:

@model("User")
export class User extends Model({
    uuid: prop<string>(),
    name: prop<string>()
}) implements Partial<IUser>{
    
    /**
     * Build composite id on init
     */
    protected onInit() {
        this.$modelId = buildCompositeIdUser(this.name, this.uuid);
    }

    /**
     * Get reference id
     */
    public getRefId(): string {
        return buildCompositeIdUser(this.name, this.uuid);
    }

    public static ref = customRef<User>("UserRef", {
        resolve(ref:Ref<User>) {
            const rootStore = findParent<RootStore>(ref, (n) => n instanceof RootStore);
            if (!rootStore) return undefined;
            return rootStore.users.get(ref.id)
        },

        onResolvedValueChange(ref:Ref<User>, newUser, oldUser) {
            if (oldUser && !newUser) {
                // if the user value we were referencing disappeared then remove the reference
                // from its parent
                detach(ref)
            }
        }
    })

}

@model("Todo")
export class Todo extends Model({
    uuid: prop<string>(),
    text: prop<string>(),
    userResponsibleRef: prop<Ref<User>>()
}) implements Partial<ITodo> {

    protected onInit() {
        this.$modelId = buildCompositeIdTodo(this.text, this.uuid);
    }

    /**
     * Get reference id
     */
    public getRefId(): string {
        return buildCompositeIdTodo(this.text, this.uuid);
    }

    @computed
    public get userResponsible():IUser {
        if (this.userResponsibleRef) {
            return this.userResponsibleRef.current
        }
        else {
            return null as any;
        }

    }
}

I believe I have achieved this here (note the @computed userResponsible property on the Todo model
Other than the obvious pain on denormalization if the ref is no longer present, is this pattern sound?

In general though, it would be nice if there was an opt in option/pattern for the magic, used with caution and with caveats fully explained.

[xaviergonz]

One question, are your user ids / todo ids globally unique or locally (they are only unique within the same class) ?

If globally unique I think that might be simplified a bit as:

@model("User")
export class User extends Model({
    // let's assume just using the uuid is good enough as a model id
    // uuid: prop<string>(),
    uuid: idProp,
    name: prop<string>()
}) implements Partial<IUser>{
    // no need to set $modelId on init, it no longer exists since we will use the uuid prop as model id
    // getRefId uses $modelId by default (or in this case it will use uuid), no need to redefine it

    public static ref = rootRef<User>("UserRef", {
        onResolvedValueChange(ref:Ref<User>, newUser, oldUser) {
            if (oldUser && !newUser) {
                // if the user value we were referencing disappeared then remove the reference
                // from its parent
                detach(ref)
            }
        }
    })

}

@model("Todo")
export class Todo extends Model({
    uuid: idProp,
    text: prop<string>(),
    userResponsibleRef: prop<Ref<User>| undefined>()
}) implements Partial<ITodo> {
    public get userResponsible():IUser | undefined {
      return this.userResponsibleRef?.maybeCurrent;
    }
}

[mashaalmemon]

Actually our ids are composite (two fields). As such using the idProp won't work for us unless we pass the id in as a parameter. However I'd rather the underlying model code build it from two fields on the fly (outside of the view of the developer using it). This is the reason why I build it onInit()

Given that, is onInit() the best place to set this.$modelId?