feat: form methods

[anuragxxd]

Description

Fixes #157

Checklist

• My code follows the contributing guidelines of this project.
• I am aware that all my commits will be squashed into a single commit, using the PR title as the commit message.
• I have performed a self-review of my own code.
• I have commented my code in hard-to-understand areas.
• I have updated the user-facing documentation to describe any new or changed behavior.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• I have not reduced the existing code coverage.

Comments

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3b7eb68

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 8, 2023 0:19am

[anuragxxd]

Hey @JaeAeich, will this suffice your use case? Please have a look! Check out this example https://cloud-components-qx37k2073-elixir-cloud-aai.vercel.app/design/components/form.html#methods-1

[JaeAeich]

@git-anurag-hub This looks perfect for the current implementation of packages. As far as I can see we shouldn't get stuck with atleast TES and WES.

To be noted though
For TES, its a large form and chances of error are high. error() method can help the user in filling the form and with success we can show the run ID of th run created.

Since the form is quite large, on success() it will cause alot of DOM manipulation and page change, maybe we shouldn't reset the form and give package-author an an option to not remove form on success and also not reset form on success.
Do you agree? I believe we can think about this stuff later as getting the package out for v1 should be out first priority.

[anuragxxd]

@git-anurag-hub This looks perfect for the current implementation of packages. As far as I can see we shouldn't get stuck with atleast TES and WES.

To be noted though For TES, its a large form and chances of error are high. error() method can help the user in filling the form and with success we can show the run ID of th run created.

Since the form is quite large, on success() it will cause alot of DOM manipulation and page change, maybe we shouldn't reset the form and give package-author an an option to not remove form on success and also not reset form on success. Do you agree? I believe we can think about this stuff later as getting the package out for v1 should be out first priority.

Make sense @JaeAeich, yes some future works here I can think are:

• Make error() pinpoint the fields. Right now they can pass it as the message prop.
• Better success() UX flow.

Also for the run id you can shoe it as the message prop.