-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
fix(workflowengine): require a VueConstructor object as operation plugin #50783
base: master
Are you sure you want to change the base?
Conversation
/backport to stable31 |
/backport to stable30 |
Might need to do the same stuff for registering |
46bdf15
to
275ddb9
Compare
solves an incompatibility issue when the providing app registers their code from an incompatible nextcloud-vue version. Also changes and clarifies WorkflowEngine API. This is necessary to stay compatible with the original way, but also promotes usage of the originally declared but never used "component" attribute on registration. Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
275ddb9
to
9ac3a96
Compare
const View = this.operation.component | ||
this.component = new View() | ||
this.component.$mount(this.$refs.operationComponent) | ||
this.component.$on('input', this.updateOperation) | ||
this.component.$props.value = this.rule.operation |
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.
Just a note, such an approach only works in Vue 2 (which is EOL since 31 Dec 2023).
In the current Vue:
- Component cannot be used as a constructor with
new component()
. Only app can, created withcreateApp(component)
. And thiscreateApp
must be from the sameVue
, ascomponent
= same issue as in the past $on
was deprecated and has been removed
Let me think about a simple alternative...
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.
Option 1: WebComponents
// In an app defining operation
import Vue from 'vue'
import wrap from '@vue/web-component-wrapper'
// Wrap Vue component into custom HTML Element
const CustomOperationElement = wrap(Vue, OperationComponent)
// Register with some UNIQ name
window.customElements.define('custom-operation', CustomElement)
// In Vue 2, wrap doesn's support disabling shadow :(
// Disable with a hack
Object.defineProperty(CustomElement.prototype, 'attachShadow', { value() { return this } })
Object.defineProperty(CustomElement.prototype, 'shadowRoot', { get() { return this } })
// ---
// In workflowengine
// <component :is="'custom-operation'" />
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.
Option 2: provide a register method so CustomOperation developers can manually mount the app.
We do it in Viewer.
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.
cc @susnux
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 prefer the webcomponent approach, but we should be consistent and either also do so on viewer or use option 2
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.
@juliusknorr I mean for the next version nextcloud/viewer#2395
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'm fine with both - but I agree the Webcomponent looks more elegant.
What would the event listener in the workflow engine look like? Could we do something like:
<component :is="'custom-operation'" @input="handleInput" />
or even use v-model
as we currently do?
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.
@vue/web-component-wrapper
docs say:
Custom events emitted on the inner Vue component are dispatched on the custom element as a CustomEvent. Additional arguments passed to $emit will be exposed as an Array as event.detail.
Sounds like event handing should work.
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.
only works in Vue 2 (which is EOL since 31 Dec 2023).
Just to clarify. Even if the server isn't about to be migrated to Vue 3 very soon, this limitation won't allow other apps to use Vue 3 and have integration with the workflow engine
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'm fine with both - but I agree the Webcomponent looks more elegant. What would the event listener in the workflow engine look like? Could we do something like:
<component :is="'custom-operation'" @input="handleInput" />
or even use
v-model
as we currently do?
Sounds like event handing should work.
Yeah, it's a little bit more complicated. Events are emitted as native custom events. So:
- You don't have the input value as the event object, but a CustomEvent object. The value is
$event.detail[0]
- You cannot use
v-model
(for the reason above) - You cannot use
input
as the custom event name, until you stop bubbling nativeinput
event
So I'd suggest to use modelValue
+ update:modelValue
event to not conflict with natives.
<component
:is="operationElementName"
:model-value="inputValue"
@update:model-value="inputValue = $event.detail[0]"
/>
Thank you all for the input here! I pushed the suggested changes hereto as well as to Talk's flow. I could not get the Also, the But I might have been holding it wrong, this is far from my area of confidence 😅 Didn't do yet:
|
@blizzz I'll have a look in the morning. I must work, I checked :D As an alternative, we can also define both options:
Then we have a quick and simple fix for the release + a better solution for the future |
if the app has to be touched anyway – it has – there is no reason to have a bridge solution there (provided WebComponents works). less is 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.
I did not take a look at the entire file - just some had a brief glance. Hope the pointers are useful. Happy to have a call to follow up.
ref="operationComponent" /> | ||
<component v-if="operation.component" | ||
:is="operation.component" | ||
@input="updateOperationByEvent" |
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.
You will need the code from @ShGKme here - the event from the component will be called update:model-value
, the prop is model-value
:
:model-value="inputValue"
@update:model-value="updateOperationByEvent"
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 said, this results in Property or method "inputValue" is not defined on the instance but referenced during render.
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.
Yes... you need to add it to the data section with a default. Insert line 107, somewhat like this:
inputValue: '',
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.
this fixes the error message at least (i knew it was pebcak)
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 @update event however does not fire
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 take your offer for a call 😎
}, | ||
async updateOperationByEvent(event) { | ||
this.$set(this.rule, 'operation', event.detail[0]) | ||
this.$refs.operationComponent.value = this.rule.operation |
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 don't think changing the value directly like this is a good idea - not sure if it would work.
Instead I see two options:
-
Use a
data
value that sets the prop:this.inputValue = $event.detail[0]
This matches the code I proposed above.
-
use
rule.operation
to set the prop in the template above (instead ofinputValue
). The line above already setsrule.operation
in a reactive way. So if you use that in the prop you should be done.
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 don't think changing the value directly like this is a good idea - not sure if it would work.
It's similar to what we did in the first commit. Only, there we interacted with a native Vue component, not a WebComponent. If I recall correctly, $props
is not available here. But i might have holding it wrong, happy to try out again. But the issue above is the first blocker.
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.
Just saw that this.rule
is a prop in this component. We really should not alter it but instead emit an event if we want the parent component to change it's value.
@@ -186,6 +190,7 @@ export default { | |||
if (this.rule.id < 0) { | |||
this.$store.dispatch('removeRule', this.rule) | |||
} else { | |||
this.$refs.operationComponent.value = this.originalRule.operation |
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 same as in updateOperationByEvent
applies here. So:
this.inputValue = this.originalRule.operation
this.$set(this.rule, 'operation', this.originalRule.operation)
Summary
solves an incompatibility issue when the providing app registers their code from an incompatible nextcloud-vue version.
Also changes and clarifies WorkflowEngine API. This is necessary to stay compatible with the original way, but also promotes usage of the originally declared but never used "component" attribute on registration.
TODO
Checklist