Context through the tree hierarchy

[samskiter]

Hi, new to TS/RN/mobx/MST so this will be a noob question.

As I understand it MST gives me a tree-like hierarchy of models. I wonder if it's possible to set a context for a portion of this tree.

For example if I had an application with several accounts - could I contextually apply the account ID to all sub-models of that account? for the purpose of API calls?

Here's an example from the MOBX documentation:

https://mobx-keystone.js.org/contexts/

const usernameCtx = createContext<string>()

@model("MyApp/SomeParent")
class SomeParent extends Model({
  username: prop<string>(),
  // ...
}) {
  onInit() {
    usernameCtx.setComputed(this, () => this.username)
  }
}

@model("MyApp/SomeDeepChild")
class SomeDeepChild extends Model({...}) {
  @modelAction
  someActionThatRequiresUsername() {
    const username = usernameCtx.get(this)
    // ...
  }

  @computed
  get someComputedThatRequiresUsername() {
    return usernameCtx.get(this) + " is awesome!"
  }
}```

What would be the equivalent in MST using the React ContextAPI? I tried to use the above but I don't seem to be able to import `createContext` from mobx - is it a deprecated function? (I understand the context API in react is newish so some libraries might have come up with their own context stuff first)

I've struggled to search for answers to this question, as every mention of 'context' + 'MST' shows me examples with React components using contexts to access MST models and using context provider tags inside those component trees.

Is the correct thing to do here to hold this contextual relationship on my react tree? My understanding of the philosophy of MST is that we have a *separate* model tree to the components tree?

[samskiter]

Just a follow up that I found this example:

mobx-state-tree/examples/bookshop/src/stores/BookStore.js

Line 16 in a4f25de

get shop() {

Is it expected to use 'getParent' for this sort of thing? I presumed that would break encapsulation?

[coolsoftwaretyler]

Hi @samskiter - yeah, I personally like getParent or getRoot for this. Nothing breaks at runtime, but some people don't like that design.

If you want something that feels less like a leaky abstraction, you could maybe do dependency injection with environments

I'll take a more in depth look at your example later this weekend, but wanted to quickly say that getParent and getRoot exist for a reason - no problem in using 'em, IMO!

[coolsoftwaretyler]

Also as a heads up, the example you gave is from MobX-Keystone, which is a different take on MobX-State-Tree. The two libraries are pretty incompatible, but they share many similarities since Keystone was an attempt to build a similar system to MST. I know it's confusing, especially since the docs site kind of looks like ours. Sorry for the mix up there.

[samskiter]

Thanks for the replies! Maybe I'm misunderstanding the 'tree' part of 'mobx state tree'. I assumed I would in some way be able to apply something to a subtree or navigate the tree as I can with react providers and contexts

…

On Sat, 9 Mar 2024, 17:57 Tyler Scott Williams, ***@***.***> wrote: Also as a heads up, the example you gave is from MobX-Keystone, which is a different take on MobX-State-Tree. The two libraries are pretty incompatible, but they share many similarities since Keystone was an attempt to build a similar system to MST. I know it's confusing, especially since the docs site kind of looks like ours. Sorry for the mix up there. — Reply to this email directly, view it on GitHub <#2162 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWOW34TMQ2KYXOW46DOXLYXNERRAVCNFSM6AAAAABEOEEVEGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOMZQHE2TC> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[coolsoftwaretyler]

Hi @samskiter - I think I'm misunderstanding your question. Trying to read your initial example, it's using MobX-Keystone context to do dependency injection. We have a similar mechanism in our own environment injection, and that helps you avoid the need to know the shape of the tree with getParent or getRoot, but you can use those to navigate the tree if you find that satisfactory.

From what I see, the MobX-Keystone context object has a lot more functionality than our environments, so I don't have a good analog to present to you. Sorry about that!

[samskiter]

My understanding is that the mobX-keystone example allows the context to be different for different parts of the state tree.

Here's a couple of extracts:

With this code, whenever the child is attached to the parent the username will be fetched from the parent.

set(node, value) - Sets the (static) value a node will provide for itself and its children. Usually called in onInit.
setComputed(node, () => value) - Sets the (computed) value a node will provide for itself and its children. Usually called in onInit.

On the other hand, is not getEnv in MST a global state?

[samskiter]

get(node) - Gets the context value for a given node (recursing up in the tree until a node has a set value or the default if none is set). Usually called in actions and computed getters. This value is reactive/observable, so never cache this value since it might get stale.

Is there an equivalent to this in MST?

[coolsoftwaretyler]

Yes, you are correct that the environment is global. I don't think we have an equivalent.

If anyone wants to see the code in action, this does not work:

import { getEnv, t } from "mobx-state-tree";

const envA = {
  name: "envA",
};

const envC = {
  name: "envC",
};

(async function () {
  const ModelC = t.model("ModelC", {}).views((self) => ({
    get environmentName() {
      return getEnv(self).name;
    },
  }));
  const ModelB = t
    .model("ModelB", {
      c: t.maybe(ModelC),
    })
    .views((self) => ({
      get environmentName() {
        return getEnv(self).name;
      },
    }));
  const ModelA = t
    .model("ModelA", {
      b: t.maybe(ModelB),
    })
    .views((self) => ({
      get environmentName() {
        return getEnv(self).name;
      },
    }));

  const c = ModelC.create({}, envC);
  const b = ModelB.create({ c });
  const a = ModelA.create({ b }, envA);
  console.log(a.environmentName, b.environmentName, c.environmentName);
})();

CodeSandbox.

You'll get an error like:

Uncaught Error: [mobx-state-tree] A state tree cannot be made part of another state tree as long as their environments are different.

I would definitely be interested to see a PR that adds some notion of contexts, but I've never needed it myself, so it would also be cool to articulate the use cases for it as well.

Sorry I don't have a better answer for ya. Perhaps MobX-Keystone is a better option for you if you need that kind of thing. Always cool to see the ecosystem push us all to be better. Maybe this discussion will inspire us to add more to MST.

[samskiter]

So to give some context - I'm imagining a situations like, say, a user is authenticated to two accounts (like you can in the gmail app) then it would seem natural that a model tree could reach out and 'get' the user id but, obviously not globally....

So maybe this code sandbox is a closer example?

I'm afraid that being 1 day into typescript and react means I'm unlikely to be able to submit a PR for this feature 😆

I noticed that mobx-keystone is far less popular than this library but promises better TS support. Honestly, I've found the [extremely long type] cannot be assigned to [another extremely long type] errors to be a little user unfriendly - is this just the nature of React/Typescript or is this fixed by the purported "better typescript support" promised by mobx-keystone.

(Not trying to bag on this project here! I'm in a learning mindset and coming from very different programming paradigms (a decade of native development with Swift etc) so just taking it all in!)

[coolsoftwaretyler]

Haha no you're all good, my friend!

I can't speak much to the popularity differential or to keystone at all since I am not involved, and I wasn't involved in MST directly until last year (other than using it). But from the outside, I think Xavier created MobX-Keystone to resolve some of those TypeScript limitations, and I understand there are some performance improvements as well. It comes with a tradeoff of a different syntax, which I personally don't like. I haven't tried keystone myself since I am very happy with MST and pretty focused on making it better, but you might find you prefer their TS implementation. Maybe someday ours will entice you back.

It makes sense that keystone also offers some enhanced functionality like context. Maybe some day we will catch up!

All that to say, no offense taken. This was a great discussion and it highlighted some important shortcomings between two libraries in our ecosystem. I hope it helps you find a good tool to use, and helps other evaluate their choices as well. It will certainly help the MST team as we consider the many different ways we can improve things here.

Good luck on your journey with TypeScript, MobX, and MST/Keystone. We will always be happy to hear from you, even when we can't be super helpful in the short term. I appreciate your time!

[samskiter]

get parent presumably doesn't work for anything deeply nested as in the example from mobx keystone?

…

On Sat, 9 Mar 2024, 19:03 Sam Duke, ***@***.***> wrote: Thanks for the replies! Maybe I'm misunderstanding the 'tree' part of 'mobx state tree'. I assumed I would in some way be able to apply something to a subtree or navigate the tree as I can with react providers and contexts On Sat, 9 Mar 2024, 17:57 Tyler Scott Williams, ***@***.***> wrote: > Also as a heads up, the example you gave is from MobX-Keystone, which is > a different take on MobX-State-Tree. The two libraries are pretty > incompatible, but they share many similarities since Keystone was an > attempt to build a similar system to MST. I know it's confusing, especially > since the docs site kind of looks like ours. Sorry for the mix up there. > > — > Reply to this email directly, view it on GitHub > <#2162 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAJWOW34TMQ2KYXOW46DOXLYXNERRAVCNFSM6AAAAABEOEEVEGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOMZQHE2TC> > . > You are receiving this because you were mentioned.Message ID: > ***@***.*** > com> >

[coolsoftwaretyler]

You can specify a number of levels to getParent: https://mobx-state-tree.js.org/API/#getparent

[tm-3]

@samskiter

I'm a little new with mst, and you probably moved on or solved this by now, but depending on how you add data, you might be able to use references:

import { types, Instance } from 'mobx-state-tree';

const ParentType = types
  .model({
    parentId: types.identifier,
    name: types.string,
  })
  .volatile((self) => ({
    someValue: 'string',
    someNumberValue: 3,
  }));

const ChildType = types
  .model({
    childId: types.identifier,
    name: types.string,
    parent: types.reference(ParentType),
  })
  .actions((s) => ({
    getParentName() {
      return s.parent.name;
    },
  }));

const Store = types
  .model({
    parentStore: types.map(ParentType),
    childStore: types.array(ChildType),
  })
  .actions((s) => ({
    addParent(parent: ParentType) {
      s.parentStore.put(parent);
    },
  }))
  .views((s) => ({
    getChildren(parentId: string) {
      return s.childStore.filter((child) => child.parent.parentId === parentId);
    },
  }));

type ParentType = Instance<typeof ParentType>;
type ChildType = Instance<typeof ChildType>;

const store = Store.create({
  parentStore: {
    '1': {
      parentId: '1',
      name: 'parent1',
    },
    '2': {
      parentId: '2',
      name: 'parent2',
    },
    '3': {
      parentId: '3',
      name: 'parent3',
    },
  },
  childStore: [
    {
      childId: '1',
      name: 'child1',
      parent: '1',
    },
    {
      childId: '2',
      name: 'child2',
      parent: '1',
    },
    {
      childId: '3',
      name: 'child3',
      parent: '3',
    },
  ],
});

const parentName = store.childStore[0].parent.name;
const parentNameOtherWay = store.childStore[0]?.getParentName();
const parentVolatile = store.parentStore.get('1')?.someValue;
const parentVolatileNumber = store.parentStore.get('1')?.someNumberValue;

const childrenOf = store.getChildren('1');
console.log(
  parentName,
  parentNameOtherWay,
  parentVolatile,
  parentVolatileNumber,
  childrenOf.map((c) => c.name)
);

I just threw this together quickly, but for recursive types you could use the types.late function if necessary. Volatile state might give you some options as well, but you'll still need a way to find the particular node you are looking for within the tree so you would have to recursively walk up the tree until you were able to find the node through some attribute.

Identifiers and references are pretty cool. Keep in mind that the identifier does not have to match anything in your persisted data(it can). It's simply a way to relate one node to another within the same store. When you access the properties of the child node you get all of the actions, views, properties of the reference.

There are a ton of ways to structure your data here and I'm not even close to being able to recommend any best or even good practices. So far I have tried to keep it simple and not nest things too deeply and it's worked out for me.

hth!