Skip to content
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

Read custom visualizations #8180

Merged
merged 32 commits into from Nov 3, 2023
Merged

Conversation

somebody1234
Copy link
Collaborator

@somebody1234 somebody1234 commented Oct 30, 2023

Pull Request Description

Important Notes

Tests are still WIP

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.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@somebody1234 somebody1234 added CI: No changelog needed Do not require a changelog entry for this PR. -gui labels Oct 30, 2023
app/gui2/shared/binaryProtocol.ts Outdated Show resolved Hide resolved
app/gui2/src/stores/visualization.ts Outdated Show resolved Hide resolved
app/gui2/src/util/visualizationMetadata.json Outdated Show resolved Hide resolved
app/gui2/src/workers/visualizationCompiler.ts Outdated Show resolved Hide resolved
app/gui2/package.json Outdated Show resolved Hide resolved
app/gui2/src/stores/visualization.ts Outdated Show resolved Hide resolved
app/gui2/src/stores/visualization.ts Outdated Show resolved Hide resolved
app/gui2/src/stores/visualization.ts Outdated Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file became big and is hard to read, moreover has no coverage in unit tests. Could we split it to multiple modules? I would see for example a separate class which keeps synchronized all maps like "typesOfVisualization", "visualizationForTypes" etc. - or maybe we could make use of the structure used by suggestion database? Also, a separate file for communication with compiler worker (applying notifications could be tested I think).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

side note: i think loadScripts fits better in its own file too, but the current logic is too specific to visualization for it to make sense to refactor out

@somebody1234
Copy link
Collaborator Author

most review issues should be addressed, but this may be [x-on-hold] depending on how busy i am?

re: binaryProtocol.ts, feel free to git checkout the original copy from develop

(note that removing styles, and reloading visualizations, are still not implemented)
(to be specific, all the infrastructure should be there, they just need a little debugging to determine how to trigger recomputation of dependencies?)

app/gui2/shared/binaryProtocol.ts Outdated Show resolved Hide resolved
app/gui2/package.json Outdated Show resolved Hide resolved
app/gui2/shared/languageServer.ts Outdated Show resolved Hide resolved
app/gui2/shared/languageServer.ts Outdated Show resolved Hide resolved
app/gui2/shared/languageServer/files.ts Outdated Show resolved Hide resolved
app/gui2/src/components/GraphEditor/GraphVisualization.vue Outdated Show resolved Hide resolved
@somebody1234
Copy link
Collaborator Author

somebody1234 commented Oct 31, 2023

things should be mostly addressed, i believe most of what's left should be writing more tests?

@farmaazon also, just wanted to know your thoughts on how stores/visualization is split now?

return JSON.parse(key)
}

export class VisualizationMetadataDb extends ReactiveDb<VisualizationId, VisualizationMetadata> {
Copy link
Contributor

@Frizi Frizi Nov 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On one hand I really don't like using extends and almost always prefer composition (except for very specific classes like Observable). But on the other hand, in this specific case it does look good, and maybe we should also move SuggestionDb to that same model. Will there ever be a situation where we want more ReactiveDb instances (i.e. tables) in the actual "database" type? If so, then we should really use composition. Otherwise I'm fine with this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm... fwiw i think it's fine to instead require Db classes to always be single tables - it's not like ReactiveDb supports multiple tables either, even though it is called a Db, right?

but yeah, the intent is for this to always be a single table - the name is supposed to mean, more or less, "a table associating each visualization type with its metadata". (i.e. a single table, where the key is the visualization type, and the value is the metadata)

@somebody1234
Copy link
Collaborator Author

... actually i don't think the mocks are that hacky after some of the newer changes

however... i think i might have to leave this PR as it is for now in favor of some stuff that's a bit more urgent.
should i maybe just merge this in assuming nothing is broken, and then clean up the story/mocks etc. later? (and perhaps open a ticket for it?)

@somebody1234
Copy link
Collaborator Author

or perhaps someone would be interested in cleaning it up

@somebody1234
Copy link
Collaborator Author

requesting one (potentially) final review for the mock impl which is kinda scuffed

@somebody1234
Copy link
Collaborator Author

@farmaazon just a heads up, i still haven't added tests for compiler messaging. i could maybe? try? but i can't really think of any tests that don't just... test that the implementation is doing exactly what the implementation is doing.

i think this may just be something better left for integration and/or e2e tests, but if you do have some ideas on what tests i can add then i'd be more than happy to add them

Copy link
Contributor

@farmaazon farmaazon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with skipping tests for compiler messaging.

@Frizi
Copy link
Contributor

Frizi commented Nov 3, 2023

Incredible work on that FS mock.

@somebody1234 somebody1234 added the CI: Ready to merge This PR is eligible for automatic merge label Nov 3, 2023
@mergify mergify bot merged commit 168e222 into develop Nov 3, 2023
32 of 34 checks passed
@mergify mergify bot deleted the wip/sb/read-custom-visualizations branch November 3, 2023 20:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-gui CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Read custom visualizations.
3 participants