Circular type references with TS 3.5

[danielkcz]

Bug report

Sandbox link or minimal reproduction code
https://github.com/FredyC/mobx-state-tree-ts3.5

Describe the expected behavior
I want to be able to use BaseModel that gives me a reference to the root model properly typed.

import { getRoot, types } from "mobx-state-tree"

import { TRootModel } from "./RootModel"

export const BaseModel = types.model().views(self => ({
  get root(): TRootModel {
    return getRoot<TRootModel>(self)
  }
}))

Describe the observed behavior

The same code works with TS < 3.4 (currently using 3.2 with it).

[mweststrate]

The second error gives the hint here: trying to infer the type of version makes it endlessly circular for typescript. Adding a type annotation at this point solves the problem, as it breaks the dependency of needing to know the type of system.version to determine the type of UserModel, which in turn needs to be know to determine the type of BaseModel in the first place:

get version(): string { /*etc */.

---

Fur future readers, the full source code was (I threw it into one file, otherwise I got lost in reading this, as the terms are meaningless to me):

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

export const BaseModel = types.model().views(self => ({
  get root(): TRootModel {
    return getRoot<TRootModel>(self)
  }
}))

export const SystemModel = BaseModel.named('System').props({
  version: types.frozen('1')
})

export interface TSystemModel extends Instance<typeof SystemModel> {}
export interface TSystemModelProps extends SnapshotIn<typeof SystemModel> {}

export const UserModel = BaseModel.named("User")
  .props({
    name: types.optional(types.string, "unknown")
  })
  .volatile(() => ({
    age: types.number
  }))
  .views(self => ({
    get version(): string /* added this annotation to break the circle */ {
      return self.root.system.version
    }
  }))

export interface TUserModel extends Instance<typeof UserModel> {}
export interface TUserModelProps extends SnapshotIn<typeof UserModel> {}

export const RootModel = types
  .model("Root")
  .props({
    system: types.optional(SystemModel, {}),
    user: types.optional(UserModel, {})
  })
  .views(self => ({
    get agedVersion() {
      return `${self.system.version} - ${self.user.age}`
    }
  }))

export interface TRootModel extends Instance<typeof RootModel> {}
export interface TRootModelProps extends SnapshotIn<typeof RootModel> {}

[danielkcz]

Well, that's not very nice :( I wonder why it worked with 3.4. Is 3.5 somehow stricter?

It's fairly inconvenient to by double typing things like that, kinda beats the reason for a typed models.

Do you possibly have some tips if something like that can be structured differently to avoid this problem?

[mweststrate]

Saying it beats the purpose is quite a strong way to express needing to do a little more work than would be strictly necessary. Actually, I think explicitly defining return types on functions is a good practice anyway, as it protects your function body against implementation errors (it makes the function signature the contract, instead of the implementation). I think it is for that reason one of the recommended rules of tslint as well. Why it behaves differently I don't know, might be very well be some low level change in TS.

…

On Mon, Jul 15, 2019 at 2:06 PM Daniel K. ***@***.***> wrote: Well, that's not very nice :( I wonder why it worked with 3.4. Is 3.5 somehow stricter? It's fairly inconvenient to by double typing things like that, kinda beats the reason for a typed model. Do you possibly have some tips if something like that can be structured differently to avoid this problem? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1341?email_source=notifications&email_token=AAN4NBEX3SGRWPGE7PJOGPDP7RR6FA5CNFSM4IDB7OLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ5PQPA#issuecomment-511375420>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN4NBC5TU4CG4RL35PUOBTP7RR6FANCNFSM4IDB7OLA> .

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or questions.