Skip to content

Comments

chore: Implement webchat pre-engagement form - render forms [CHI-3696]#3897

Open
gpaoloni wants to merge 9 commits intomasterfrom
gian_CHI-3696
Open

chore: Implement webchat pre-engagement form - render forms [CHI-3696]#3897
gpaoloni wants to merge 9 commits intomasterfrom
gian_CHI-3696

Conversation

@gpaoloni
Copy link
Collaborator

@gpaoloni gpaoloni commented Feb 12, 2026

Description

This PR implements the rendering of pre engagement form, based on the form definitions introduced in #3865.

Checklist

Other Related Issues

None

Verification steps

AFTER YOU MERGE

  1. Cut a release tag using the Github workflow. Wait for it to complete and notify in the #aselo-deploys Slack channel.
  2. Comment on the ticket with the release tag version AND any additional instructions required to configure an environment to test the changes.
  3. Only then move the ticket into the QA column in JIRA

You are responsible for ensuring the above steps are completed. If you move a ticket into QA without advising what version to test, the QA team will assume the latest tag has the changes. If it does not, the following confusion is on you! :-P

@gpaoloni gpaoloni requested a review from stephenhand February 19, 2026 19:46
@gpaoloni gpaoloni marked this pull request as ready for review February 19, 2026 19:48
Copy link
Collaborator

@stephenhand stephenhand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One design question. Also, we should add some tests

"react": "^17.0.2",
"react-app-rewired": "^2.2.1",
"react-dom": "^17.0.2",
"react-hook-form": "^6.15.8",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since our long term aim is to move away from using this, is there any chance we could avoid adding it to a new project?

Copy link
Collaborator Author

@gpaoloni gpaoloni Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly don't know why that would be our long term goal. As I've said when this was discussed, we would have to implement and maintain all the validation rules, handle dirty states that are used in some components, among others features that we rely on. I don't think removing rhf is a good idea as I don't see the benefit. However, if we end up removing it, I would do so in a separate refactor PR if you don't mind, as I'd rather avoid having to write all the validations and form state management that are required for the components introduced in this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants