lorean_victor

Yeah we reached that point pretty early on while developing the PaaS with the tool, so had to incorporate support for mixed synchronous JS blocks. you can check out how to do that here: https://medium.com/connect-platform/inline-coding-in-connect...

to a pretty limited degree, could you elaborate more?

yeah really not bad at all, didn't think of that solution originally. edited the article accordingly.

yes you are right the constructors aren't indeed needed.

as for the complexity of the graph, basically the way I see it is that even this promised based method is a way to solve the problem of putting the graph into the proper promise-based format (for example, chain doA and doC and return an array of their result) vs simply drawing the intended graph. I mean it does take sometime to get used to it specially if you are really used to just working with code (which I myself originally was), but since the graph is the more intuitive way to represent it compared to other methods, after going through the learning curve it seems to be less complex and easier to manage.

that said its not like I have conducted proper academic research on the matter and it might as well be a pretty subjective thing.

Shouldn't it be like

doE: doC, doB, doA doD: doB

etc?

anyways the problem with this approach is that doD() is assumed to be a general function (or statement or async command) that is not by definition bound to doB(), but rather in this specific case we need it to be executed after doB() is done.

so in your code sample, would 'aOut' be a promise or a value? in case it is a promise, then basically doC() would needed to be re-written to handle when it gets a promised value instead of an actual value, and if not, then doA() must be invoked synchronously, i.e. the `let bOut = doB()` statement must be awaiting `let aOut = doA()` statement which is not what the desired async execution flow is.

yeah I think the article actually starts with that Promise-based code snippet. Even the sequential graph is based on the promise-based code.

Yeah I don't think so that on its own the visual programming makes any difference (or even adds any value). The main point here is that the "visual programming" is coincidentally a solution for async programming.

and to be fair its a really redundant format. I mean I personally would prefer the current undesirable situation rather than doing XML-based coding all day.

Haven't seen that before (although not tested the website on iOS much). Maybe this link helps instead:

https://github.com/CONNECT-platform/connect-platform

And the product itself is a development platform so I would highly recommend checking it out on desktop. Will checkout the issue of the website on iOS asap as well.