elsa-workflows / elsa-workflows/elsa-core

Javascript expressions possible improvements.

Open
#807 2 comments 0 reactions 0 assignees View on GitHub
enhancement prio low question triaged
Dominant language
C#
Stars
7.9k
Forks
1.5k
Avg merge
15h 22m
Merged PRs (30d)
114

Description

https://github.com/elsa-workflows/elsa-core/issues/785 has been closed but the general discussion that started in it should continue I think, resulting in some agreement on how to write activity outputs so they better integrate with JavaScript expressions.

So @craigfowler said:
>
> I mostly-agree. To some extents though this is just the nature of what we are doing.
> ## I don't think it's a great idea to try and "be more like JavaScript"
>
> Jint allows us to refer-to & manipulate objects from JavaScript language & syntax. But - Elsa is still fundamentally a .NET application, so a lot of the objects we are using came "from the .NET world". _JavaScript is the foreigner here and .NET objects are the natives_.

Well, as a "hard core" programmer, same as you are, I agree with you and I probably could live with it, kind of.
However I envision that users using designer do not care what language Elsa is written in.
They just care what they see in designer and designer says JavaScript.
Moreover, they could be less programmer oriented, and for them confusion of mixing two expression kinds could be even worse.
This is my humble opinion/feeling only and I understand others might feel different.

In any case, you need to document what the Elsa "Javascript" (quotes intentional since it is not 100% javascript and is not 100% C#) can do and how it behaves. And that documentation should be targeted (as much as possible) to users who don't make their living writing code.

That being said I do understand that it could take a lot of work to make it happen.
But we should try to make "Dual Javascript" "blend" as much as we can.

Again pretending to be designer user only, the first thing I'd like to see is that all activity outputs (or models, don't know what is better name) are capable of doing `JSON.stringify(ActivityName.Output)`.

Why I chose this one? Well if you don't read the documentation, which ton of users don't even when it exists :), this would probably be the first step you would do when trying to discover what does the Activity output look like :).
Moreover, since stringify does some number of things I believe that if we reach that some of the other JavaScript stuff that currently doesn't work would work too....

How to do that is another question. ....
A wild ideas, maybe the answer is forcing all activity outputs/models to implement some interface for which we know plays good with Jint. Haven't studied Jint in enough details to know if this is possible, or if it would "constraint" what model can be too much.
Maybe just documenting this "stringify" requirement so activity model developer is aware of it and can test it.......

Sorry for the longer post, let me know what you think :).....

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.