-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursive MST models and TypeScript #417
Comments
It's not great but we've worked around this by explicitly typing the model reference: import {types, IModelType} from 'mobx-state-tree';
interface INode {
childs: INode[]
}
const Node: IModelType<Partial<INode>, INode> = types.model({
childs: types.optional(types.array(types.late(() => Node)), [])
})
const node = Node.create();
node.childs; // INode.childs: INode[] |
Uhm, the example in the readme I think worked with 2.4 in strict mode, maybe with 2.5 with strict it now throws, so we could update to the example by @praxxis :) |
Hi, I have the same problem. Can someone give me a hand? I look at the test("late should allow circular references", () => {
// TypeScript is'nt smart enough to infer self referencing types.
const Node = types.model({
childs: types.optional(types.array(types.late(() => Node)), [])
})
expect(() => Node.create()).not.toThrow()
expect(() => Node.create({ childs: [{}, { childs: [] }] })).not.toThrow()
})
test("late should describe correctly circular references", () => {
// TypeScript is'nt smart enough to infer self referencing types.
const Node = types.model("Node", {
childs: types.array(types.late(() => Node))
})
expect(Node.describe()).toEqual("{ childs: Node[] }")
})
Any idea what I should do if I'm using TypeScript? 😅 My case is a little trickier because I have other fields. For example,
How can I modify the workaround about to handle this case? Thank you 🙌 Edit: Yay! I got it! 😃🎉 In case any other noobs (like me) stumble onto this, maybe this will help: interface INode {
name: string;
age: number;
children: INode[];
}
const Node: IModelType<Partial<INode>, INode> = types.model("Node", {
name: types.string,
age: types.number,
children: types.optional(types.array(types.late(() => Node)), [])
}); |
So am I correct that the only way to solve 'circular dependency' issues with TypeScript is to create all needed TS interfaces manually (?) and use it because MST makes everything as |
@mweststrate I would appreciate your input on this UPDT: Oh, I see your comment now: #658 (comment) |
@aksonov: While we're probably all waiting for a generic solution check out if the factory pattern in #1011 (comment) can be used as workaround for your use case. |
I'm currently doing some conferences, on which I really have to focus, so I
hope it can wait two weeks 😊
Op do 25 okt. 2018 18:39 schreef Rainer Wittmann <notifications@github.com>:
… @aksonov <https://github.com/aksonov>: While we're probably all waiting
for a generic solution check out if the factory pattern in #1011 (comment)
<#1011 (comment)>
can be used as workaround for your use case.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#417 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhPz0prfpNK_xGY1MYdHBwKqyOiWNks5uoek6gaJpZM4PsD9I>
.
|
This issue continues to exist. Adding |
Please check the last comments from #943 |
In the documentation of type.late (https://github.com/mobxjs/mobx-state-tree/blob/master/src/types/utility-types/late.ts), the following section of documentation specifies how we should deal with recursive MST model definitions:
However, when implementing this example using TypeScript 2.5.2 (with noImplicitAny set to true), this results in the following TypeScript error:
If we set noImplicitAny in our TsConfig to false, then the error is gone. However, there is no typing information available on the MST model anymore. I can instantiate Node with any snapshot, without it ever triggering a typing error. I assume the snapshot resolves to the 'any' type, thus no type checking is performed in this case.
Are there any suggestions to solve this issue?
The text was updated successfully, but these errors were encountered: