-
Notifications
You must be signed in to change notification settings - Fork 167
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
KOGITO-3195: Fork KIE Editors #494
Conversation
…#25) * Everything working except for Standalone Editors * Standalone Editors working. * Cleanup * Fix tests * Reduce Editor Envelope size. Remove PMML Marshalelr from BPMN and SceSim envelopes. * Remove unnecessary loader
@tiagobento The desktop, Chrome and online editor tests are random failures. I ran all the tests locally in Windows virtual machine and they passed but I tried to lower the number of processors in the virtual machine to 2 and in some of the runs I was able to see this screen with two loading popups what is suspicious: I saw this only when the online editor server was started and cypress tests were executed (processor usage was on 100%). Manually (without Cypress) I was not able to reproduce it. |
@tomasdavidorg Thanks for taking a look! Chrome has a feature called CPU throttling that might be able to help reproduce that issue, have you tried it? |
@domhanak Yes, Standalone Editors and Desktop are ok locally on my macOS. |
@tiagobento Thanks for the tip but I was still not able to reproduce it. With the The CPU throttling the loading popup is just there for a longer time and at the end the editor appears. However I was able to reproduce it by opening 10 windows of online editor. On every I clicked "Try dmn sample" and 4 of them end up with the loading issue. In the console I found:
|
@tomasdavidorg I can't reproduce those. Can you please give more details? Are you running it locally with |
@tiagobento I am able to reproduce it only on Windows 10 virtual machine (Virtual box). The machine has 2 CPUs, 7 GB RAM. Inside machine I start
file.mp4 |
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.
The Monaco editor for "standalone" breaks with this PR.
Can you also advise why the need to change imports? Unless you communicate the reasoning to all contributors the old style will creep back in and whatever issue the change fixes will return.
@@ -31,7 +30,6 @@ module.exports = [ | |||
libraryTarget: "commonjs2", | |||
}, | |||
externals: [nodeExternals({ modulesDir: "../../node_modules" })], | |||
plugins: [new MonacoWebpackPlugin()], |
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.
Now you've removed the MonacoWebpackPlugin
the "standalone" PMML editor no longer has support for:-
- Syntax highlighting
- Code complete
You may need to add a similar entry to this so that the standalone editor works correctly?
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.
Hi Michael!
WebpackMonacoPlugin was just a fancy way of rebuilding the Monaco Editor. We're actually fancier than that as we have our own publication of Monaco under @kiegroup/monaco-editor
😎
Jokes aside, I can't reproduce it. See this VSIX I just generared.
vscode_extension_kogito_kie_editors_0.9.1.vsix.zip
The icons are missing like @jomarko reported, though.
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.
@tiagobento The VSCode extension is not affected, only pmml-editor
when run with yarn run start
. This is the webapp we use use day to day development.
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.
Oh, okay. Forgot about that! Good catch, I'll take a look.
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.
Fixed in 1b458cf!
Hi @kelvah I've added you for review too. |
01Some monaco editor issue (#494 (review)) is present also for DMN in VS code. Once autocompletion suggestions are displayed for DMN literal expression, the icons seems to be not loaded. |
EDIT: Online Editor: |
@tomasdavidorg Can you report this one under https://issues.redhat.com/browse/KOGITO-5039? |
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 confirm the icons are now present id DMN visx.
- I tested manually the DMN and SCESIM editors. (Created small model with ~5 nodes and 4 scenarios for it).
- I didn't checked code
- I didn't checked other platforms than VS Code.
@tiagobento Reported: https://issues.redhat.com/browse/KOGITO-5068 |
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.
Thank-you for the fix @tiagobento.
@tiagobento I have approved; but please be sure to communicate "...why the need to change imports? Unless you communicate the reasoning to all contributors the old style will creep back in and whatever issue the change fixes will return". |
@manstis The change on imports is related to item 5 on the description. Basically by importing the classes directly from their most specific directory, we are only importing what we really need. That's called tree-shaking. This is done automatically when using ES Modules, but since we're still on CommonJS, we had to do this change. There's an "automatic" way of doing it, but it's quite "magical" so I preferred to do that manually. On the upcoming weeks we'll be migrating from CommonJS to ESM, meaning that tree-shaking will be automatic and we will be able to import |
@kelvah @domhanak @tomasdavidorg Already got approvals for QE and the PMML Editor team, can we proceed and merge this PR? |
@tiagobento Please wait for review by @LuboTerifaj. We agreed that @LuboTerifaj will do some more checks of the BPMN editor. Thanks. |
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.
Hi @tiagobento, everything looks good for the pmml-editor. I left you a couple of questions. Thank you.
"@kogito-tooling/quarkus-runner-unpacked": "0.7.0-SNAPSHOT", | ||
"@kogito-tooling/scesim-editor-unpacked": "7.53.0-Final", | ||
"@kogito-tooling/scesim-editor-unpacked": "8.0.0-SNAPSHOT-20210430.130828", | ||
"monaco-editor": "^0.23.0", |
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 am bit confused. Why did you add a monaco-editor
dep here?
Maybe I'm wrong but isn't @kiegroup/monaco-editor
acting like a wrapper for monaco? In that case I think it should replace it as a dependency
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.
Good catch! monaco-editor@^0.23.0
is listed as a devDependency on @kiegroup/monaco-editor
as we didn't want to enforce the use of the original package when using it. The problem is that the type definitions are all in the original package, so we need to download it here too. When releasing @kiegroup/monaco-editor@0.2.3
I didn't remember that, so we would need a new @kiegroup/monaco-editor
release listing monaco-editor@^0.23.0
as a dependency instead of devDependency. If it's okay I can do it on a new PR.
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.
It's okay for me 👍
@@ -31,7 +31,7 @@ import { Provider } from "react-redux"; | |||
import mergeReducers from "combine-reducer"; | |||
import { HistoryContext, HistoryService } from "./history"; | |||
import { LandingPage } from "./components/LandingPage/templates"; | |||
import { Page } from "@patternfly/react-core"; | |||
import { Page } from "@patternfly/react-core/dist/js/components/Page"; |
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 saw your comments about "manual" tree shacking. Did you give a try to what PF suggests (babel-plugin-transform-imports
for our case I think)?
Is it the magical solution you mentioned that wasn't ideal?
Asking because the manual change looks quite invasive.
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.
Hi! Yes. I'm not saying it isn't ideal, I just didn't thought I wanted a tool dealing with the imports. It's one more thing to take care of and on the upcoming weeks we'll have ESM as default anyways..
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 understand. Thank you.
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.
Hi all,
I didn't find any issues in VSCode bpmn editor.
Thank you!
Thanks @LuboTerifaj. |
We finally have a snapshot version of the new forked editors from
kogito-editors-java
. This PR is a huge milestone for Kogito Tooling, so it deserves a good description. I'll try to summarise everything included on this PR, as it's the result of a couple of month's work and we did many improvements that were not planned beforehand!8.0.0-SNAPSHOT-20210430.130828
editorContext
from theinit
method of the Envelopes. This context is now part of the Init args we pass when opening Editors.@patternfly/*
dependencies. When we're using ESM, this will be done automatically, but for now, we have to be extra-careful with our imports to not bring the entire PatternFly parts into our bundles.Editor
interface accept custom APIs. This will be very useful when we need to provide different APIs for some of our Editors. Note that the Channels are still using the Editors with the defaultEditor
API.StateControl
class.CompositeEditorFactory
as we don't want to Editors to be bundled in the same Envelope.