-
Notifications
You must be signed in to change notification settings - Fork 171
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
Check for existing scope on possible cyclic dependencies #4292
Conversation
Job #8358: Bundle Size — 62.78MiB (~+0.01%).
Warning Bundle contains 64 duplicate packages - View duplicate packages Bundle metrics (1 change)
Bundle size by type (1 change)
View job #8358 report View fix/multiple-import-handling branch activity |
return existingScope == null ? left(msg) : right(existingScope) | ||
}, | ||
(resolvedFilePath) => { | ||
resolvedFromThisOrigin[toImport] = null // We use null as a marker to indicate that we have started resolving, but not completed yet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't we use some other marker like 'started-resolving'
? I think the !== undefined
(from above) is very unexpressive, and the shape of the code would stay the same
Problem:
Whilst evaluating a project inside the canvas, when we reach an import statement that has already been resolved we assume that it is a cyclic dependency, and fall back to the default import handling, meaning we won't wrap the imported components and therefore can't focus and edit them.
This can be shown by having a file A import file B, and then have multiple files import file A, which is shown here - in this project, the
Text
component cannot be focused, as the import statementimport { Text } from '/src/text'
insidecard.js
is evaluated twice. To see that working on this branch, test the project hereFix:
Rather than immediately assume that we have hit upon a cyclic dependency that we can't handle, we now keep a reference to the scope created by each import, and return that if it exists. If no such scope exists (and we have already resolved that import), then we will fall back to the default import handling.