Closed
Description
We do a lot of server-side rendering. And if we want to keep it at least partially, we cannot fully use Vue 3 for that.
htmx fills the gap to do so while making the site more interactive. Though I'm not contributing much to the frontend lately, I did hear only good stuff about it. And if you look at the two pull requests, making the two components interactive in Vue 3 would have been more or less a complete rewrite. The pull requests only had to undergo minor code changes to make it work.
In terms of maintenance and refactoring, that is a huge advantage.
example pulls:
Activity
yardenshoham commentedon Jan 21, 2024
I think adding htmx is a good idea. The pull requests speak for themselves, they are small and easy to maintain. htmx fits Gitea very well.
denyskon commentedon Jan 21, 2024
HTMX makes it easier to develop interactive UI using our already present template structure. And I think it is better to introduce something we can use to make existing UI better than to wait for someone to rebuild everything using a new framework.
wxiaoguang commentedon Jan 21, 2024
My question is: does htmx really help and will be widely used in Gitea?
I have been following htmx for some time. My feeling is:
hx-headers='{"x-csrf-token": "{{.CsrfToken}}"}'
for every reuqest?link-action
andform-fetch-action
already handles CSRF token automatically.The samples PRs #28871 and #28872 are good demo for htmx, but they are too simple and didn't handle error messages / loading indicators. Are there some complex samples for showing how htmx would work for a complex case in Gitea? For example, comment editing, PR merging?
So, IMO the only useful part of htmx at the moment is the "replacing inner/outer html by ajax", while it is quite simple and could (should) be implemented by existing "link-action" and "form-fetch-action". Other htmx features are unlikely useful in foreseeable future.
(I don't mean objection, while I think these questions needs to be clearly answered and some should be written into the guideline / devtest.tmpl if most people would like to use htmx)
jolheiser commentedon Jan 21, 2024
I would be for using htmx over our home-rolled solutions, and for slowly increasing its usage where it would be beneficial.
But I also agree we need to come up with some solid plan for reducing our fracture of JS solutions.
With our current mix I think new additions need to planned out carefully.
[-]Decide to use xtmx or not[/-][+]Decide to use htmx or not[/+]yardenshoham commentedon Jan 21, 2024
From https://htmx.org/docs/#requests:
In the event of an error response from the server (e.g. a 404 or a 501), htmx will trigger the htmx:responseError event, which you can handle.
In the event of a connection error, the htmx:sendError event will be triggered.
https://htmx.org/docs/#indicators
Why would we recreate the logic htmx excels at and maintain it?
We can use https://htmx.org/docs/#inheritance to set it on a root tag, that way all requests include it
I don't have experience creating modals. I don't think that the fact htmx has features we already implemented should block us from using it, or any other library that implements functionality we have. I wouldn't use htmx with Vue, I'd use htmx when I don't need the power of Vue.
What do you mean by fragile? Yes, linting is missing in htmx, what kind of rules would you like to enforce?
What's wrong with their error handling? I can work to change it. Just like the previous behavior of the buttons I changed, there were no loading indicators.
It's not supposed to be used in complex cases, at least I won't force it to.
I don't think you've considered the varying possibilities to "replacing inner/outer html by ajax". Are we going to reimplement
hx-target
,hx-swap
, andhx-select
? This is no small feat, it's a maintenance challengeI am very new to htmx. Those PRs are the first time I used it. We should try it out and play with it instead of immediately enforcing some prematurely written guidelines.
wxiaoguang commentedon Jan 22, 2024
Thank you for the detailed answers.
That's a complex question, and I do not think it could be easily answered by yes or no.
Let's see some examples:
Gitea is not a small project, so there are a lot of details which are not easy to be satisfied by 3rdparty library, they need to be customized somewhat.
For "htmx": I am just showing a choice for "not introducing if there are some foreseeable problems".
And I have a feeling that "replacing inner/outer html by ajax" is not that complex in Gitea, no need to fully "reimplement hx-target, hx-swap, and hx-select" like htmx or reinvent the wheel again.
(I just would like to express the background, don't mean yes / no here)
I didn't mean they were wrong, but the previous behavior is not ideal doesn't mean the new behavior is right.
And actually the behaviors are changed, that why I asked the questions about error handling / loading indicator:
Since we are improving the UI, I think it is a good chance to give end users better UI responses.
In my mind, our
link-action
andform-fetch-action
could handle this case well. If we use htmx, do we need to remind every contributor to manually addd error handling / loading indicator?If let us predict, after introducing htmx, in which case the
link-action
/form-fetch-action
should be used, and in which casehtmx
should be used?puni9869 commentedon Jan 22, 2024
Having experience with both htmx and vuejs, I currently utilize htmx for smaller applications. However, I've encountered limitations when integrating it into big project, especially on complex screens such as code review and the front landing page, where various UI elements are in play. Considering the challenges faced, I believe using to Vue3 would be a more favorable option. It allows us to leverage existing solutions and avoid reinventing the wheel. I leave the final decision to the TOC/maintainers for their consideration.
yardenshoham commentedon Jan 22, 2024
Thanks for the detailed comment.
Sure, but we have more libraries we don't customize than ones we do.
I'd love to see the sample PRs recreated in
link-action
/form-fetch-action
to compare maintainability.Regarding the error handling and loading indicator, I am open to add changes, I don't see these as blockers to use htmx.
The distinction seems pretty clear to me,
link-action
/form-fetch-action
if you want a full page load, otherwisehtmx
.wxiaoguang commentedon Jan 22, 2024
I am not sure whether I have enough time recently to work on a sample. So feel free to continue the htmx related design. I think there might be some htmx options or mechanisms to make the error handling / loading indicator easier (no need to write them everytime).
I think it is feasible. And at the moment we had better forbid some htmx features like "htmx modal" / "htmx script" to make sure there are consistent designs in code base (unless there is another complete plan to refactor existing code to a new framework).
My opinion: I could vote for htmx if the standards could be defined (including: general error handling, avoid some unnecessary features like htmx script).
yardenshoham commentedon Jan 22, 2024
@go-gitea/technical-oversight-committee please write here your official decision if we can add
htmx
or not34 remaining items