Mobx: Cycle detected in computed property

[sisp]

I'm getting a "Cycle detected" exception in a computed property which in my opinion should not occur. This is a small reproducible example: https://codesandbox.io/s/mobx-cycle-detected-so7p9

I think there should be no exception because (1) the uniqueValues computed property only depends on all other items but not itself (so no trivial cycle) and (2) I'm using structural comparison which should detect that the result of uniqueValues will return the (structurally) same array after at most few cyclic iterations.

Is this a bug or am I missing something?

[urugator]

I'm using structural comparison which should detect that the result of uniqueValues will return the (structurally) same array after at most few cyclic iterations.

But the nested uniqueValues is accessed before the computation returns ... there is no returned value, therefore there is nothing to compare ...
The "next iteration" is invoked before the previous one has a chance to return something...
Does it make sense?

[sisp]

Yes, it does. I totally missed that. Thanks for pointing it out!

This may be a bit beyond the scope of a MobX issue, but I need to perform this cyclic computation and in my head it should be possible. Any idea how I can do it without a cycle?

[FredyC]

@sisp Perhaps you want to explain why do you need that? For once this is very confusing to have cycles like that for anyone who will read after you. The example is simplified, I get that, but doesn't make any sense like that.

• You have a store with items
• Each item has a value
• You are asking item what are other unique items? Shouldn't that query be a part of Store itself?

[sisp]

Sure, let's see if that helps.

I'm modeling "variable names" (like source code variables) which exist in "scopes" and I'd like to detect collisions of variable names that have the same scope. There are two kinds of variables: local and (sort of) global. Local variables have a single scope and global variables have a root scope plus additional computed scopes by computing the set union of all the local variables' scopes that exist under the root scope (think of variable scopes and closures). The cycle I'm facing is caused by computing the set union of all variables' scopes (also the global ones which have partly computed scopes).

Does this make any sense?

[sisp]

It seems like I can work around this problem by using a reaction.

[sisp]

It seems like MobX is doing the right thing and the problem I sketched is in fact not even related to MobX. I think the issue can be closed unless there's more to discuss.

Thanks a lot for the helpful discussion!

[lock[bot]]

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.