It is possibly also the only reasonable place where we can have heuristics to
de-duplicate URLs that point to the same repo, e.g., non-canonical GitHub repos URLs.

This will also let us think in terms of reusable widgets. I am not sure how important that would be in our case, but couple of use-cases are

• we can make swh search or the origin browser a public widget, it can be integrated in any external website with just two lines of HTML code.
• Many UI elements are in fact the same kind in SWH (eg: folder/file raw, list view etc). Most this can be re-used inside the system. This will make it efficient and easy to manage.

@zack Thanks for the input. I will start thinking about accessibility as well.
Many pages, including 'swh search' will not function as expected without enabling JS. So, I would say JS is integral.

In T3157#66041, @jayeshv wrote:

This will simplify branches view implementation. You should create a diff to handle it.

Yes. Let me check it's side effects as well. The 'archive.lookup_snapshot' is called from multiple places.

This will simplify branches view implementation. You should create a diff to handle it.

In T3157#66039, @jayeshv wrote:

@anlambert Thank you. I will try to do some refactoring here.

@anlambert Thank you. I will try to do some refactoring here.

There is no need to use JavaScript here from my point of view.

The ideal fix would be to refactor the code to move the entire presentation logic to the template engine. (We already have a check in the template to show "The list of branches is empty" message in case the branch list is empty. But, i think this case will never occur with the current server code)

More answers after further reading and analysis.

This will eventually cause a 404 error when the user search for a non existing branch name in the UI. I don't think this is the intended behavior.

@anlambert The server code seems to have an issue when branches are filtered by name.
"swh.web.common.archive.lookup_snapshot" function is raising an error if the number of searched branches is 0.
raise
This will eventually cause a 404 error when the user search for a non existing branch name in the UI. I don't think this is the intended behavior.

Removing the "easy hack" tag, because that's actually much harder than expected :D

I'm adding here a note about something to consider in terms of pros/cons: accessibility. As for the most part we are archiving textual information, we really want it to be accessible for all users. Right now we go further than that, ensuring that the Web UI can be browser with a textual browser: so, for instance, w3m https://archive.softwareheritage.org/swh:1:cnt:c839dea9e8e6f0528b468214348fee8669b305b2 just works out of the box. I'm not up to date on what's the accessibility impact of current JS frameworks, nor that we should have as a requirement that the archive is browsable without JavaScript enabled (as per today's standards "browsable with free javascript" is probably good enough for us, and we have a curl-able API anyway), but accessibility per se is definitely going to be a requirement.

It's deployed now.

@rdicosmo That's the issue ^ (unrelated to T3361 in the end), the workers were not suscribed to consume from that queue yet.

Can it work with a content SWHID with context?

In T3351#65594, @anlambert wrote:

I made some quick hacks in swh-web to see if it was easily feasible to have standalone source code view that could be embedded into an iframe, the answer is yes !

This is great to know (and see :-)

• The fix was deployed on webapp1 and moma
• The refresh script was manually launched:

root@webapp1:~# /usr/local/bin/refresh-savecodenow-statuses
Successfully updated 140 save request(s).

The previous requests were correctly refreshed and are now displaying the right status.

Will be deployed with version v0.0.310 of the webapp (build in progress)