feat(wes): create Lit package for WES

[JaeAeich]

Description

Create a package for lit migration for WES and add Create run component

Fixes #148

[changeset-bot]

⚠️ No Changeset found

Latest commit: b1d767b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
cloud-components	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 14, 2023 7:49am

[JaeAeich]

@git-anurag-hub This is wesCreate, the fields and form are set. Was able to create workflows, need to figure out how to show response though but maybe that part of design package implementation.

I think we should maybe merge it and then work on those things namely:

• Reposponse
• styles

or do them in this PR itself either is fine by me.

Even though there is nothing to see here just a form which console logs if success, @uniqueg if you can try to create a workflow as well 🙌 maybe I might be missing some important fields.

[anuragxxd]

Yeah make sense @JaeAeich, we need to implement 2/3 more functionalities to the form component like:

• success() method
• error() method
• loading() method

I will create the issue for the same!

[uniqueg]

@JaeAeich can you please tell me on Slack what exactly you need, in terms of a workflow?

[JaeAeich]

@git-anurag-hub Please review this.

[anuragxxd]

LGTM! Maybe you can merge this after #168

[JaeAeich]

@git-anurag-hub Please review it. @uniqueg you can try to create workflow from the deployement, do check it out if you can.

[uniqueg]

This looks awesome! 🤩 Great job @JaeAeich & @git-anurag-hub.

And the test workflow worked great for me! 🚀

I do have, of course, a couple of points, but they shouldn't block this PR. You can of course include them here, if they are easy to do. Otherwise, maybe create issues for them to tackle later:

• It would be great to have descriptions or tool tips for the different params. For example, workflow URL can be used to reference an uploaded file, as per the spec (though that may currently not be implemented in proWES). Noboody would be able to know that unless they do know the spec. Of course the question is, where to source these descriptions/tool tips from - but that we could discuss in the issue (probably just hardcoding them would be best; they probably won't change often, if at all).

• I think the tags field is missing (it is defined in the 1.0.1 version of the specs, which we should minimally support)

• I would reorder the fields to have as follows (from top to bottonm): "Workflow URL", "Workflow Type", "Workflow Type Version", "Workflow Parameters". The reason is that to me it seems to me more natural that I would want to decide which workflow I'm running first, before worrying about any params or the engine. For that I may need to select the files first, then reference the main descriptor file, say what type and type version of descriptor it is. After all of that I would put the "Tags" and then finally the "Workflow Engine Parameters". Note that in WES v1.1.0, we will have two more (optional) workflow engine-related parameters (workflow engine name and version), so at that point I think it would make sense to collapse them.

• I would only capitalize the first word for the field names, e.g., "Workflow type" instead of "Workflow Type"

• For the workflow attachments, it would be nice (and I think also important) to see the names of the files that have been uploaded, especially since it may be necessary to select one of them as the "Workflow URL". And I think it is a better user experience if the user can delete individual files, and if a new selection of files does not clear the old selection. So for example, I might select a primary CWL descriptor file and two secondary descriptor files. But accidentally I have selected a wrong file. So I should be able to remove the wrong file and then select only the single missing descriptor file, without having to select again the two others.

• As an extension of the issue above, it would actually be great if after selecting one or more files for upload and listing their file names and a button to remove them, there would also be a checkbox that would optionally allow selecting exactly one file as the Workflow URL. If selected, this should auto-populate (and ideally hidden or grayed out unless a file is unselected) the "Workflow URL" field with the name of the file. As an alternative (possibly even better) we could maybe have an upload file button next to the "Workflow URL" field (maybe with an OR in between) that can only be used to select the primary descriptor file. If it is used, the workflow URL is then auto-populated. Additional files can then still be attached through the button/field at the bottom.

• It would be nice if the "Workflow Parameters" and "Workflow Engine Parameters" would also accept YAML (which would then be converted to JSON), as it is easier for humans to manipulate YAML. For example, {"input":{"class":"File","path":"https://is.muni.cz/pics/design/r/znak_MU.png"}} is much harder to type/construct than:

  input:
    class: File
    path: https://is.muni.cz/pics/design/r/znak_MU.png

• Finally, I think it would be good to highlight the "Submit" button (bold font, colored background) and gray it out until all required values have been added.

[JaeAeich]

@git-anurag-hub I have opened issues for the features stated above (#172 , #173, #174, #175). Please review the issues as well as they are feat/fixes for design package, we might need to see if the solution should be abstracted or left to pacakge-author.

[anuragxxd]

Thanks @JaeAeich for identified issues. I've added comments to the respective issues for clarity.

Fortunately, these are all minor fixes, with the exception of the file multiple input selection issue, which may require more time to address.

For the time being, as a workaround for file multiple input selection, you can utilize the array structure and add the files as children to a single selection field. This approach will display all the file names, and users will be able to delete individual files. However, the downside is that users will need to click the "Add" button each time they want to include a new file. Considering the advantages of this implementation, I believe this workaround is reasonable. @uniqueg can confirm whether to go ahead with the implementation.

Apart from the issues you raised, I believe the current form component implementation can handle the remaining concerns.

[uniqueg]

Thanks @git-anurag-hub. I actually think that currently, we do not absolutely need better file support. Because even if we can see the uploaded files listed and can remove individual files and so on, it will still be a blocker that subdirectory structures cannot be preserved with the current implementation. In real world use cases, all files required by a workflow will almost never be in a single flat directory. See my new comment for details.

So I would rather leave it as it is for now, until we can address it properly.

[uniqueg]

Please also note that I have added two more issues: #179 & #180

[anuragxxd]

LGTM