Decide to use htmx or not #28880

6543 · 2024-01-21T13:14:31Z

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:

The text was updated successfully, but these errors were encountered:

yardenshoham · 2024-01-21T13:19:44Z

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 · 2024-01-21T13:28:18Z

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 · 2024-01-21T14:18:40Z

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:

How does htmx handle error messages and network failure in Gitea? How does it handle the "loading" indicator?
The basic feature like "replace inner html" could be easily implement by a few lines in our framework, ex: we already have "link-action" and "form-fetch-action"
Does it need to repeatly write hx-headers='{"x-csrf-token": "{{.CsrfToken}}"}' for every reuqest? link-action and form-fetch-action already handles CSRF token automatically.
Some advanced features overlaps with existing mechanisms, eg: modal. Should new code use Fomantic/Gitea Modal, or htmx's modal? What if Vue component needs to show a modal, htmx isn't designed to work with Vue IMO.
Some advanced features like "htmx script" is quite fragile and I don't know how to lint/test them. It would cause maintainability problems.

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 · 2024-01-21T15:38:04Z

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.

yardenshoham · 2024-01-21T16:51:14Z

How does htmx handle error messages and network failure in Gitea?

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.

How does it handle the "loading" indicator?

https://htmx.org/docs/#indicators

The basic feature like "replace inner html" could be easily implement by a few lines in our framework, ex: we already have "link-action" and "form-fetch-action"

Why would we recreate the logic htmx excels at and maintain it?

Does it need to repeatly write hx-headers='{"x-csrf-token": "{{.CsrfToken}}"}' for every reuqest? link-action and form-fetch-action already handles CSRF token automatically.

We can use https://htmx.org/docs/#inheritance to set it on a root tag, that way all requests include it

Some advanced features overlaps with existing mechanisms, eg: modal. Should new code use Fomantic/Gitea Modal, or htmx's modal? What if Vue component needs to show a modal, htmx isn't designed to work with Vue IMO.

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.

Some advanced features like "htmx script" is quite fragile and I don't know how to lint/test them. It would cause maintainability problems.

What do you mean by fragile? Yes, linting is missing in htmx, what kind of rules would you like to enforce?

The samples PRs #28871 and #28872 are good demo for htmx, but they are too simple and didn't handle error messages / loading indicators.

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.

Are there some complex samples for showing how htmx would work for a complex case in Gitea? For example, comment editing, PR merging?

It's not supposed to be used in complex cases, at least I won't force it to.

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 think you've considered the varying possibilities to "replacing inner/outer html by ajax". Are we going to reimplement hx-target, hx-swap, and hx-select? This is no small feat, it's a maintenance challenge

(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)

I 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 · 2024-01-22T03:05:02Z

Thank you for the detailed answers.

The basic feature like "replace inner html" could be easily implement by a few lines in our framework, ex: we already have "link-action" and "form-fetch-action"

Why would we recreate the logic htmx excels at and maintain it?

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 was using unrolled/render, but it had to be dropped Drop "unrolled/render" package #23965
Golang has a official and widely used template system, but we have to customize it a lot ("template context" support)
There is "autoresize" https://github.com/github/textarea-autosize, but Gitea has to copy & rewrite all the code.
Gitea has to use its own methods to show/hide elements (showElem/hideElem)
There are many modern editors, but Gitea has to write its own one.

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)

The samples PRs #28871 and #28872 are good demo for htmx, but they are too simple and didn't handle error messages / loading indicators.

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.

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:

Old behavior: if there is a network error, then the users are able to see an error page
New behavior: according to my test, if there is a network error, there is no UI response when I click the button. That's why I do not think it is ideal.

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 and form-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?

Are there some complex samples for showing how htmx would work for a complex case in Gitea? For example, comment editing, PR merging?

It's not supposed to be used in complex cases, at least I won't force it to.

If let us predict, after introducing htmx, in which case the link-action / form-fetch-action should be used, and in which case htmx should be used?

puni9869 · 2024-01-22T05:25:27Z

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 · 2024-01-22T06:48:32Z

Thanks for the detailed comment.

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.

Sure, but we have more libraries we don't customize than ones we do.

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'd love to see the sample PRs recreated in link-action / form-fetch-action to compare maintainability.

And actually the behaviors are changed, that why I asked the questions about error handling / loading indicator:

Regarding the error handling and loading indicator, I am open to add changes, I don't see these as blockers to use htmx.

If let us predict, after introducing htmx, in which case the link-action / form-fetch-action should be used, and in which case htmx should be used?

The distinction seems pretty clear to me, link-action / form-fetch-action if you want a full page load, otherwise htmx.

wxiaoguang · 2024-01-22T15:14:45Z

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.

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).

The distinction seems pretty clear to me, link-action / form-fetch-action if you want a full page load, otherwise htmx.

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 · 2024-01-22T15:25:15Z

@go-gitea/technical-oversight-committee please write here your official decision if we can add htmx or not

yardenshoham · 2024-01-23T14:46:55Z

I will take "no comment" as silent approval

jolheiser · 2024-01-23T15:16:23Z

My comment is largely as it was above.

I would be for an exploratory PR (similar to the one we recently had and reverted) and we should use that PR to try and define some guardrails around its usage moving forward, as well as giving the opportunity for anyone to be critical of any tradeoffs.
I think that would be easier to do in a concrete example PR.

I love (the idea of) htmx, my main concern is more fracturing of our frontend framework(s).

delvh · 2024-01-23T15:32:00Z

So, the overall consensus I sense is the following:
We are in favor of introducing HTMX if the PR adding it also adds clear contribution guidelines where, how, and what parts of HTMX to use.

yardenshoham · 2024-01-23T18:43:01Z

I created #28908 with error handling and request indicators

lunny · 2024-01-24T01:40:50Z

Just notice this closed.

I concens following questions.

If we introduce htmx, should it replace vue3 in future or not?
If we introduce htmx and keep vue3 at the same time, then we have both vue3 and htmx. So when should contributors use vue3 and when should use htmx when sending a PR?
I couldn't find htmx is better than ajax/fetch with vue3 even in Introduce htmx and use it to avoid full page load on Subscribe and Follow #28908 . For every request, now we need to create an extra template file, but when doing the same with vue3, we just return json content.
Less people know htmx and contributors have to learn both htmx and vue3, but htmx has no special feature that vue3/javascript cannot finish. So introducing htmx may prevent contributors to contribute more.
If one button will trigger multiple changes which is not a simple dive replacement, so we have to swithc to vue3 to finish it? Or should we do mutiple requests?

wolfogre · 2024-01-24T03:11:56Z

I will take "no comment" as silent approval

I abstain and respect others' choice since it's the first time I've heard of htmx. Sorry to bother, but I meant to read others' discussions and learn 😄, not give silent approval.

techknowlogick · 2024-01-24T16:34:18Z

Hi, chiming in as well. While I am a fan of htmx and use it elsewhere, I am cautious to include it in Gitea itself regardless of benefits for the following reasons:

Including an additional way of accomplishing something can duplicate patterns, adding to the overhead in analyzing how something could be accomplished.
Including a new way of doing something without already entirely removing something that we have fully deprecated (jQuery)
There is then something that is less well known that does mean that new contributors have to learn before using

I'd be interested in hearing @silverwind's thoughts due to their contributions to the frontend, and being the top voted person in the latest TOC election.

I do see the benefits of it though (see reasons others have listed above).

I realize this isn't a yes/no to the question, but I think it is a valuable discussion to have with any big change of direction (similar to how we did with changing the routing library to chi)

yardenshoham · 2024-01-24T17:30:58Z

If we introduce htmx, should it replace vue3 in future or not?

No, vue3 is more powerful. htmx is for simple interactions.

If we introduce htmx and keep vue3 at the same time, then we have both vue3 and htmx. So when should contributors use vue3 and when should use htmx when sending a PR?

By order of reactivity:

link-action / form-fetch-action for a full page load
htmx for simple, minimal reactivity
vue3 for full reactivity

I couldn't find htmx is better than ajax/fetch with vue3 even in Introduce htmx and use it to avoid full page load on Subscribe and Follow #28908 . For every request, now we need to create an extra template file, but when doing the same with vue3, we just return json content.

If I compare it with #28914 it seems using ajax/fetch with vue3 is more lines and overall more complex.

Less people know htmx and contributors have to learn both htmx and vue3, but htmx has no special feature that vue3/javascript cannot finish. So introducing htmx may prevent contributors to contribute more.

Yes but the number of lines needed to achieve the same is drastically different, with vue3 using much more.

If one button will trigger multiple changes which is not a simple dive replacement, so we have to swithc to vue3 to finish it? Or should we do mutiple requests?

If htmx can't provide something, use vue3. I believe htmx covers a lot of use cases, but not all.

lunny · 2024-01-25T04:04:39Z

The code lines are not much more than htmx. I think the Cons is the layout will be blink, maybe I need some css to fix the height and width.

6543 · 2024-01-25T21:55:22Z

vue3 is nice if you have complex things ... but if we use it everywhere we will loose the ability to have static rendered things. e.g. at the moment server side rendered HTML can be crawled, saved in the wayback machine, used on JS-restricted browsers ...

with htmx ... we can still program as we do with templates on the server-side while archiving "modern website feeling"

summary

vue3: client-side rendering only
htmx: server-side rendering + interactive client side

puni9869 · 2024-01-26T08:52:15Z

All views are same and pointing in the same direction. Let's introduce the htmx.

anbraten · 2024-01-26T14:54:58Z

(Accidentally posted this originally on #28908)

Looks like a pretty promising approach using htmx for gitea. One thing I would like to throw into the discussions is how updating UI through events send from the server (websocket / sse) would be handled in the future for things like #2287 or #25661.

There seems to be https://htmx.org/extensions/web-sockets/.

If not would it mean that gitea would use:

htmx: server-side rendering + interactive client side
vue3: complex client-side rendering
jQuery / some vanilla JS to update UI on websocket / sse events?

6543 · 2024-01-26T19:57:47Z

We want to ged rid of jQuery ... else yes thats what at least i have in mind :)

puni9869 · 2024-01-27T05:15:17Z

We want to ged rid of jQuery ... else yes thats what at least i have in mind :)

We cannot get rid of jQuery real soon, honestly. We are too much jQuery.

anbraten · 2024-01-27T14:08:05Z

Did a first attempt on implementing how the websocket "realtime" updating could look like #28958

silverwind · 2024-01-27T14:16:48Z

I don't have much of an opionion on htmx really. Overall it seems to be suited for some limited use cases like content replacement from fetch/ws. But for many complex user cases, we will certainly have to resort to JS and Vue. It seems reasonably small, though, so I guess the performance impact of loading it shouldn't be too much.

lunny · 2024-01-27T14:27:54Z

It's unclear for small and big. There is no clear rule for which should use vue+js and which should use htmx.

denyskon · 2024-01-27T14:31:30Z

It looks to me currently like there are much more pros than possible cons of adopting HTMX. It seems to fit well into our current template structure, lowers the amount of development needed for interactive components, lowers the amount of client side rendering, and also seems to make it easier to implement features like websockets.

@lunny I'd do htmx as long as it is possible because it allows us to continue using go templates. Of course there are pages like the action run view where the whole page has to be interactive, but as long as this isn't the case and the htmx implementation is easier than the vue one, I'd go with htmx.

6543 · 2024-01-27T14:35:33Z

looking at lunnys example pull just for the simple change ... the JS got way more conplex and we got way more lines of code ...

lunny · 2024-01-27T14:59:57Z

looking at lunnys example pull just for the simple change ... the JS got way more conplex and we got way more lines of code ...

But it's not too much. And it will keep the frontend users only one consistent technique to contribute to Gitea. I'm not a frontend guy, I think it can be shorter for frontend guys.

6543 · 2024-01-27T15:01:28Z

I think we can say htmx is accepted at this point?

…`Follow` (#28908) - Closes #28880 This change introduces htmx with the hope we could use it to make Gitea more reactive while keeping our "HTML rendered on the server" approach. - Add `htmx.js` that imports `htmx.org` and initializes error toasts - Place `hx-headers='{"x-csrf-token": "{{.CsrfToken}}"}'` on the `<body>` tag so every request that htmx sends is authenticated - Place `hx-swap="outerHTML"` on the `<body>` tag so the response of each htmx request replaces the tag it targets (as opposed to its inner content) - Place `hx-push-url="false"` on the `<body>` tag so no changes to the URL happen in `<form>` tags - Add the `is-loading` class during request ### Error toasts in action ![errors](https://github.com/go-gitea/gitea/assets/20454870/181a1beb-1cb8-4858-abe8-fa1fc3f5b8f3) ## Don't do a full page load when clicking the subscribe button - Refactor the form around the subscribe button into its own template - Use htmx to perform the form submission - `hx-boost="true"` to prevent the default form submission behavior of a full page load - `hx-sync="this:replace"` to replace the current request (in case the button is clicked again before the response is returned) - `hx-target="this"` to replace the form tag with the new form tag - Change the backend response to return a `<form>` tag instead of a redirect to the issue page ### Before ![subscribe_before](https://github.com/go-gitea/gitea/assets/20454870/cb2439a2-c3c0-425c-8d3c-5d646b1cdc28) ### After ![subscribe_after](https://github.com/go-gitea/gitea/assets/20454870/6fcd77d8-7b11-40b0-af4f-b152aaad787c) ## Don't do a full page load when clicking the follow button - Use htmx to perform the button request - `hx-post="{{.ContextUser.HomeLink}}?action=follow"` to send a POST request to follow the user - `hx-target="#profile-avatar-card"` to target the card div for replacement - `hx-indicator="#profile-avatar-card"` to place the loading indicator on the card - Change the backend response to return a `<div>` tag (the card) instead of a redirect to the user page ### Before ![follow_before](https://github.com/go-gitea/gitea/assets/20454870/a210b643-6e74-4ff9-8e61-d658c62edf1f) ### After ![follow_after](https://github.com/go-gitea/gitea/assets/20454870/5bb19ae9-0d59-4ae3-b538-4c83334e4722) --------- Signed-off-by: Yarden Shoham <[email protected]> Co-authored-by: 6543 <[email protected]> Co-authored-by: Giteabot <[email protected]>

…`Follow` (go-gitea#28908) - Closes go-gitea#28880 This change introduces htmx with the hope we could use it to make Gitea more reactive while keeping our "HTML rendered on the server" approach. - Add `htmx.js` that imports `htmx.org` and initializes error toasts - Place `hx-headers='{"x-csrf-token": "{{.CsrfToken}}"}'` on the `<body>` tag so every request that htmx sends is authenticated - Place `hx-swap="outerHTML"` on the `<body>` tag so the response of each htmx request replaces the tag it targets (as opposed to its inner content) - Place `hx-push-url="false"` on the `<body>` tag so no changes to the URL happen in `<form>` tags - Add the `is-loading` class during request ### Error toasts in action ![errors](https://github.com/go-gitea/gitea/assets/20454870/181a1beb-1cb8-4858-abe8-fa1fc3f5b8f3) ## Don't do a full page load when clicking the subscribe button - Refactor the form around the subscribe button into its own template - Use htmx to perform the form submission - `hx-boost="true"` to prevent the default form submission behavior of a full page load - `hx-sync="this:replace"` to replace the current request (in case the button is clicked again before the response is returned) - `hx-target="this"` to replace the form tag with the new form tag - Change the backend response to return a `<form>` tag instead of a redirect to the issue page ### Before ![subscribe_before](https://github.com/go-gitea/gitea/assets/20454870/cb2439a2-c3c0-425c-8d3c-5d646b1cdc28) ### After ![subscribe_after](https://github.com/go-gitea/gitea/assets/20454870/6fcd77d8-7b11-40b0-af4f-b152aaad787c) ## Don't do a full page load when clicking the follow button - Use htmx to perform the button request - `hx-post="{{.ContextUser.HomeLink}}?action=follow"` to send a POST request to follow the user - `hx-target="#profile-avatar-card"` to target the card div for replacement - `hx-indicator="#profile-avatar-card"` to place the loading indicator on the card - Change the backend response to return a `<div>` tag (the card) instead of a redirect to the user page ### Before ![follow_before](https://github.com/go-gitea/gitea/assets/20454870/a210b643-6e74-4ff9-8e61-d658c62edf1f) ### After ![follow_after](https://github.com/go-gitea/gitea/assets/20454870/5bb19ae9-0d59-4ae3-b538-4c83334e4722) --------- Signed-off-by: Yarden Shoham <[email protected]> Co-authored-by: 6543 <[email protected]> Co-authored-by: Giteabot <[email protected]>

6543 added the topic/ui Change the appearance of the Gitea UI label Jan 21, 2024

6543 mentioned this issue Jan 21, 2024

Don't do a full page load when clicking the subscribe button #28871

Merged

yardenshoham mentioned this issue Jan 21, 2024

Revert adding htmx until we finaly decide to add it #28879

Merged

denyskon added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jan 21, 2024

KN4CK3R changed the title ~~Decide to use xtmx or not~~ Decide to use htmx or not Jan 21, 2024

yardenshoham closed this as completed Jan 23, 2024

lunny reopened this Jan 24, 2024

yardenshoham added topic/ui-interaction Change the process how users use Gitea instead of the visual appearance and removed topic/ui Change the appearance of the Gitea UI labels Jan 25, 2024

6543 assigned silverwind Jan 27, 2024

silverwind removed their assignment Jan 27, 2024

anbraten mentioned this issue Jan 27, 2024

Live removal of issue comments using htmx websocket #28958

Open

3 tasks

yardenshoham mentioned this issue Jan 29, 2024

Introduce htmx and use it to avoid full page load on Subscribe and Follow #28908

Merged

6543 closed this as completed in #28908 Jan 30, 2024

go-gitea locked as resolved and limited conversation to collaborators Jan 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Decide to use htmx or not #28880

Decide to use htmx or not #28880

6543 commented Jan 21, 2024 •

edited

Loading

yardenshoham commented Jan 21, 2024

denyskon commented Jan 21, 2024

wxiaoguang commented Jan 21, 2024 •

edited

Loading

jolheiser commented Jan 21, 2024

yardenshoham commented Jan 21, 2024

wxiaoguang commented Jan 22, 2024

puni9869 commented Jan 22, 2024 •

edited

Loading

yardenshoham commented Jan 22, 2024

wxiaoguang commented Jan 22, 2024 •

edited

Loading

yardenshoham commented Jan 22, 2024

yardenshoham commented Jan 23, 2024

jolheiser commented Jan 23, 2024

delvh commented Jan 23, 2024

yardenshoham commented Jan 23, 2024 •

edited

Loading

lunny commented Jan 24, 2024 •

edited

Loading

wolfogre commented Jan 24, 2024

techknowlogick commented Jan 24, 2024

yardenshoham commented Jan 24, 2024

lunny commented Jan 25, 2024

6543 commented Jan 25, 2024 •

edited

Loading

puni9869 commented Jan 26, 2024 •

edited

Loading

anbraten commented Jan 26, 2024

6543 commented Jan 26, 2024

puni9869 commented Jan 27, 2024 •

edited by 6543

Loading

anbraten commented Jan 27, 2024

silverwind commented Jan 27, 2024

lunny commented Jan 27, 2024

denyskon commented Jan 27, 2024

6543 commented Jan 27, 2024

lunny commented Jan 27, 2024

6543 commented Jan 27, 2024

Decide to use htmx or not #28880

Decide to use htmx or not #28880

Comments

6543 commented Jan 21, 2024 • edited Loading

yardenshoham commented Jan 21, 2024

denyskon commented Jan 21, 2024

wxiaoguang commented Jan 21, 2024 • edited Loading

jolheiser commented Jan 21, 2024

yardenshoham commented Jan 21, 2024

wxiaoguang commented Jan 22, 2024

puni9869 commented Jan 22, 2024 • edited Loading

yardenshoham commented Jan 22, 2024

wxiaoguang commented Jan 22, 2024 • edited Loading

yardenshoham commented Jan 22, 2024

yardenshoham commented Jan 23, 2024

jolheiser commented Jan 23, 2024

delvh commented Jan 23, 2024

yardenshoham commented Jan 23, 2024 • edited Loading

lunny commented Jan 24, 2024 • edited Loading

wolfogre commented Jan 24, 2024

techknowlogick commented Jan 24, 2024

yardenshoham commented Jan 24, 2024

lunny commented Jan 25, 2024

6543 commented Jan 25, 2024 • edited Loading

summary

puni9869 commented Jan 26, 2024 • edited Loading

anbraten commented Jan 26, 2024

6543 commented Jan 26, 2024

puni9869 commented Jan 27, 2024 • edited by 6543 Loading

anbraten commented Jan 27, 2024

silverwind commented Jan 27, 2024

lunny commented Jan 27, 2024

denyskon commented Jan 27, 2024

6543 commented Jan 27, 2024

lunny commented Jan 27, 2024

6543 commented Jan 27, 2024

6543 commented Jan 21, 2024 •

edited

Loading

wxiaoguang commented Jan 21, 2024 •

edited

Loading

puni9869 commented Jan 22, 2024 •

edited

Loading

wxiaoguang commented Jan 22, 2024 •

edited

Loading

yardenshoham commented Jan 23, 2024 •

edited

Loading

lunny commented Jan 24, 2024 •

edited

Loading

6543 commented Jan 25, 2024 •

edited

Loading

puni9869 commented Jan 26, 2024 •

edited

Loading

puni9869 commented Jan 27, 2024 •

edited by 6543

Loading