New webhook page supports quick switching type

[kerwin612]

New webhook page supports quick switching type

Sometimes user select the wrong type when creating a new webhook. User need to return to the list page and click the Add button again to select it.
This PR is in the add page, user can click the type-icon in the right-top-corner to quickly switch different types of webhooks.

[puni9869]

Please don't do this. :( Try to give a meaningful commit message. Easy for maintainers to review the PR commit by commit.

Here is the Guideline.
https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md

[kerwin612]

Please don't do this. :( Try to give a meaningful commit message. Easy for maintainers to review the PR commit by commit.

Here is the Guideline. https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md

Sorry, that is a temp log, accidentally submitted up; I've re-edited it now.

[puni9869]

Please don't do this. :( Try to give a meaningful commit message. Easy for maintainers to review the PR commit by commit.

Here is the Guideline. https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md

Sorry, that is a temp log, accidentally submitted up; I've re-edited it now.

Thanks @kerwin612 for considering this feedback and making maintainers life easy for future. Appreciated your efforts in this PR.
Kudos 💯

[silverwind]

This has multiple issues. On overview page, it renders a empty button:

On view page, it renders the icon partially outside the header (because english font is not as large as chinese):

Also, the UX with that button seems strange. I could not guess this icon is clickable by looking at the UI.

I feel like webhook type should be a <select> style dropdown element in the form itself, and switching it should ideally also preserve any previously entered values for fields that are in both old and new form.

[kerwin612]

This has multiple issues. On overview page, it renders a empty button:

On view page, it renders the icon partially outside the header (because english font is not as large as chinese): Also, the UX with that button seems strange. I could not guess this icon is clickable by looking at the UI.

I feel like webhook type should be a <select> style dropdown element in the form itself, and switching it should ideally also preserve any previously entered values for fields that are in both old and new form.

When I submit PR, the style issues you mentioned does not exist. It may be that the modification of master during the period brings compatibility problems. I will re-adapt it. I will also consider the solution that you mentioned to take webhook type as part of form and replace it with <select>.

[silverwind]

<select> dropdown would be ideal, you can take a hint from user management where depending on the value of the auth source dropdown, the form's fields change:

[kerwin612]

<select> dropdown would be ideal, you can take a hint from user management where depending on the value of the auth source dropdown, the form's fields change:

I tried what you said and it didn't look good because the webhook type with icon;

[silverwind]

You wouldn't show a icon in this case, just a dropdown with the type name like in the screenshot.

[kerwin612]

You wouldn't show a icon in this case, just a dropdown with the type name like in the screenshot.

I completely understand; however, what I considered at the beginning was that the entire form was divided into different templates according to different types, and It is not appropriate to put the switch type in each form template, so I thought of using the icon in the upper right corner to switch;

[kerwin612]

The current PR UX is as follows:

[kerwin612]

Another implementation is as follows:

@silverwind @lunny

[lunny]

Another implementation is as follows:

@silverwind @lunny

I would like the second, some benefits we will gain from the design.

• It's straight forward
• It's possible to change the following options according the first selection
• An search box could be added in webhook type selection box

[kerwin612]

Another implementation is as follows:
@silverwind @lunny

I would like the second, some benefits we will gain from the design.

• It's straight forward
• It's possible to change the following options according the first selection
• An search box could be added in webhook type selection box

I merged the second implementation into the current branch.
I don't think there's a need to add a search box to the current (fewer) options.
Teams discuss it? I look forward to hearing from you!

[silverwind]

Maybe I'm wrong, but I think #29114 has now implemented what this PR set out to do, right?

[kerwin612]

Maybe I'm wrong, but I think #29114 has now implemented what this PR set out to do, right?

I don't understand very much, I submitted this PR in 23 years, and also made changes according to the audit suggestions, why there has been no administrator response to this PR, and the PR you mentioned was submitted in 24 years, and it can be merged very quickly;

[lunny]

Maybe I'm wrong, but I think #29114 has now implemented what this PR set out to do, right?

I don't understand very much, I submitted this PR in 23 years, and also made changes according to the audit suggestions, why there has been no administrator response to this PR, and the PR you mentioned was submitted in 24 years, and it can be merged very quickly;

Sorry for the slow reviews. Can #29114 satisfy your requirements?