- User Since
- Mar 17 2021, 3:56 PM (12 w, 5 d)
Changed Promise to use async/await.
Updating to changes from origin/master
Fri, Jun 11
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.
Thu, Jun 10
This will simplify branches view implementation. You should create a diff to handle it.
@anlambert Thank you. I will try to do some refactoring here.
Wed, Jun 9
@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.
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.
Tue, Jun 8
Mon, Jun 7
Wed, Jun 2
Tue, Jun 1
2: If we have to add a UI component, do we have a design or example for that? (maybe a generic one for both branches and Releases, the "search branches" widget in github looks nice)
@anlambert I have a few questions regarding this task.
1: Should we add a filter UI component in the page or just a query param is enough?
2: If we have to add a UI component, do we have a design or example for that? (maybe a generic one for both branches and Releases)
3: What about the API /snapshot/<id>, should we add the possibility of this filter there as well?
4: The branches seem to be randomly sorted over Date. Is that for a reason or something we should address?