AC Flows -> New action: Wait for callback

Wappler General Need Help
1

Given that now we can call javascript it would be great to have an action in flows that just waits for a callback to continue with the next steps.

So basically the async/promise and await workflow.

Right now if we call a javascript there is no easy way to return to the flow that initiated the call.

I am thinking in the terms of adding the wait for callback step and getting automatically a piece of code to copy and paste in our callback function et voila the flow continues where it was waiting.

2

Actually if the JavaScript function returns a promise, then the flow will wait till it is completed before proceeding.

Correctly if I’m wrong @patrick

As a background explanation- all flows steps are actually internal JavaScript promise functions.

1 Like
3

I tried but it didn’t happen.

toast.fire(options).then(result => {
		if (result.value) {									
		}
                else {
	                if (url) {
			//(window.location = "/"+url
			}
			else {
			}
	         } 
   }

I commented out the redirect in code and added a browser.goto action in the flow just after the js run but it didn’t work on success nor failure.

4

Tried a bunch of things and I didn’t manage to make it wait for the callback.
Is this something implemented @patrick?
I may be looking at this the wrong way

5

Don’t worry. I got it to work :slight_smile:

6

So what was the final solution :slight_smile: ?

7

None. It just works. I was messing up my promise resolve :smiley:
Edit: “I was also two minor versions behind. Maybe something was changed/added?”

1 Like
8

I am back here :slight_smile: I need further insight.

What does the flow promise expect me to return or call from my external JS so the chain is broken and the flow doesn’t continue?

10

Will a

return Promise.reject()

be OK or am I setting myself up for future failure? :slight_smile:

11

A reject is like an error, it will stop the flow and go to the catch if you have that setup.

12

I went that route but on the second modal I am getting an uncaught exception coming from the Promise and that’s bugging me.

Kapture 2020-05-04 at 20.25.06
Kapture 2020-05-04 at 20.25.062058×926 1.83 MB

uncaught exception: Dismissed

The most noticeable difference is that the first modal is called from a normal flow and the second one from an inline flow. Don’t know if there are any differences about how both approaches handle promises.

13

The browser shows that error in the console because there was no catch(), so there was no error handling. In the flow component I catch the errors and the error message is stored in the lastError parameter. It also has an option throwError to actually throw the error again.

The inline flow doesn’t have these options. I could probably catch the errors there also and do nothing with them instead of the current behavior. Btw. there is no actual error thrown, it is actually just a warning that you didn’t catch the error.

1 Like
14

Ok. That would explain the different behaviour. Regarding the console error that is not an actual error I’m fine with that. All in all I just wanted to know if I was safe using reject() which it seems that I am.

Regarding adding the same error handling to the inline flows it’s not urgent nor important for me for now so no pressure from my side.

Thanks @patrick for the further insights on how flows work.