Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shepherd a cleanup of the BinderHub UI #4152

Open
1 of 7 tasks
yuvipanda opened this issue May 29, 2024 · 1 comment
Open
1 of 7 tasks

Shepherd a cleanup of the BinderHub UI #4152

yuvipanda opened this issue May 29, 2024 · 1 comment
Assignees

Comments

@yuvipanda
Copy link
Member

yuvipanda commented May 29, 2024

Context

As part of #4109, we're going to be using the BinderHub UI for ephemeral hubs.

The UI is currently janky, hard to modify and a bit unloved. When I first wrote it in like, 2017, the first line of frontend code written said:

/* If this file gets over 200 lines of code long (not counting docs / comments), start using a framework

That line is still there, while the line count is of course far over 200.

This has serious consequences for users.

  1. The frontend is hard to work on for most modern frontend devs, making any features that touch the frontend hard to implement. The frontend is also hard to work on for the people who already know how the frontend works as well, so it's not necessarily a 'trade-off' here.
  2. There's a lot of 'refresh the page, maybe the error will go away?' style text in the UI, because good error handling (and reconnects) aren't present. And they aren't present because the frontend is hard to touch.
  3. It should share code with jupyterhub-fancy-profiles to the extent possible. It already does for the binderhub API client, but should for other aspects too.
  4. Any UX improvements we may want to make are basically currently impossible.

Proposal

There's good apetite for a frontend rewrite (based on jupyterhub/binderhub#774), and is what I'd have done in 2019 if not for circumstances unrelated to Jupyter / code that prevented me from doing so. Now, I propose we just go forward with this, and complete the rewrite into something modern.

This has to be done with a good eye on not tying up too many of 2i2c's engineering resources, which should be primarily focused on the infrastructural issues outlined as various components of #4109. To that end, I've gotten some review capacity from @batpad (as well as enthusiasm from other, non-2i2c BinderHub maintainers) to help shepherd this through.

This is a bit of a slow burn, consistent work thing that will probably take a month or so to complete, and should not block any other binderhub work

Updates and actions

No response

Tasks

@yuvipanda
Copy link
Member Author

This could either be in the 'community good citizen' bucket or 'product dev' bucket, am not sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant