-
Notifications
You must be signed in to change notification settings - Fork 323
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
Set output evaluation context for a single node #8440
Conversation
…mplementation for AST replacement Untested The matched segments also need to be hidden to, but we need to make sure that the propagated content edits have the correct offset.
…text in the future
A little issue in logic: Kapture.2023-12-05.at.13.07.29.mp4When using the button near the node, context switch expressions should never stack; instead, we should replace the existing expression with the correct one. Having a “no-op” expression, like enabling output context in the “live” environment is totally okay, and should be considered as no context switch expression present on a node. |
@vitvakatu Hmm... that would mean you can't have different overrides for different environments, right? |
Yes, this is how the old GUI is implemented. We can confirm with @jdunkerley to make sure. I tried to find the actual discussion around this behavior but failed (there were a lot of drastic changes to the design). I’m sure that any operation on button shouldn’t cause the change in the visible node’s expression. |
@vitvakatu note that there are alternatives that still preserve this behavior - I think ideally we would recursively hide all context overrides, but only modify the override for the current context (or add one, if none are for the current context) |
@Frizi thoughts on using widgets for this instead? i think it'd be a cleaner (+ more generic?) solution, but the issue is that we have to communicate the "is node overridden" data all the way up the tree back to the |
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.
Any chance for output context overwriting tests? They could be E2E tests if UT would be hard, and they can be done in a separate PR.
i'll see what i can do for UT |
Warnings about `onScopeDispose` being called outside an effect scope Errors caused by unhandled promise rejections
Re-requesting review from @farmaazon for feedback on UT: Implementation |
i think the new approach is a huge bandaid. but for now it works, and hopefully most of the jank can be removed once we get real AST edits? |
oh yeah, one minor (okay, major) issue: for now at least, i've made the new AST types public, because i need to read and mutate them outside of |
requesting review from @kazcw because of ast-related changes... maybe this task should be delayed until we have edits? |
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.
I will need to make some changes to the AST-editing support here to fit my planned direction for the APIs, but I think it's OK to merge; I can update it in-tree in my next PR.
return mockNode() | ||
} | ||
|
||
export function waitForMainModule(projectStore?: ProjectStore) { |
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.
I can't find any usages of this function. Can it be removed?
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.
was required previously when I used component tests for GraphNode
import { Rect } from '../src/util/rect' | ||
import { Vec2 } from '../src/util/vec2' | ||
|
||
export const graphNavigator: GraphNavigator = { |
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.
Why does this have to be mocked? I feel like no providers should need any mocking, except for things related to network requests.
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.
previously we had component tests for GraphNode... I guess the correct solution is maybe to use a wrapper component then?
but also, we're no longer doing component tests so it's not like these are currently used either.
|
||
// It is currently not feasible to use generics here, as the type of the component's emits | ||
// is not exposed. | ||
export function handleEmit(wrapper: VueWrapper<any>, event: string, fn: (...args: any[]) => void) { |
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.
Is this used anywhere?
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.
as above, previously used for component tests. i figured it's fine to keep it if we may want to do component testing in the future, but i have no problems with removing all unused code because we are probably not planning to do that anytime soon anyway.
app/gui2/src/util/ast/match.ts
Outdated
placeholder, | ||
) | ||
if (replacements.length !== 0) { | ||
// throw new Error(`${replacements.length} unused replacements.`) |
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.
Is this error commented out unintentionally?
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.
no - nice catch, thanks, will fix.
For posterity: the additional logs added on errors were added because Vitest was throwing "unhandled exception" errors . Note also that the fix that worked there, was to add mocks for the LS and data server. |
Pull Request Description
Important Notes
None
Screenshots
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
The documentation has been updated, if necessary.Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
Unit tests have been written where possible.If GUI codebase was changed, the GUI was tested when built using./run ide build
.