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

blueprintjs removal #4006

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

maxphilippov
Copy link
Collaborator

This is an attempt to remove BlueprintJS from the project. This is pretty huge in terms of what it changes so I might have missed something, but I believed that the things came out pretty simple and manageable. What I saw during this cleanup is that we've redefined a lot of BP styling etc. making it almost our own implementation.

BlueprintJS is gone from package.json so you have to reinstall node_modules to check this properly.

Things missing:

  1. I didn't handle the Escape key bind to close new Dialog. I saw other discussions (esc-key in group create & -edit close the whole stack, not the last dialog #2268, Settings should be closable in sub-pages with escape key #3868) regarding how we should handle a stack of open windows and close only the latest one.
  2. I didn't remove bp4- class overrides (almost all of them done in either dev_rocket or dev_minimal themes), so this is definitely an open discussion (should we make up new names, add these classes to new elements or we can come up with something else). If you worked on these themes, please hit me up.

It also opens up an easier way to update React since we don't have to manage BlueprintJS too.

@WofWca
Copy link
Collaborator

WofWca commented Jul 4, 2024

About dialogs: not sure if you're aware, but now HTML has a native <dialog> which handles all these dismiss and stack things pretty well.

)
}
)

export const DeltaProgressBar = function (
props: React.PropsWithChildren<{
progress: number
intent?: Intent
intent?: string
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to actually implement that, commit incoming

@farooqkz
Copy link
Collaborator

farooqkz commented Jul 4, 2024

I can't do a review on the PR today(can't concentrate due to bad sleep pattern). But my opinion is mixed. You are doing BP removal which is desired but I am not in favor of big PRs as they need extensive testing and review. IMO, in such a bug codebase, a big PR might do more bad than good unless the review and testing is really extensive. Nevertheless, As I said removal of BP is very much wanted as a major upgrade of React and many other changes are softly dependent on it.

@farooqkz
Copy link
Collaborator

farooqkz commented Jul 4, 2024

BTW, It's good that you haven't touched the Gallery component as there is another PR for it.

@maxphilippov
Copy link
Collaborator Author

I can't do a review on the PR today(can't concentrate due to bad sleep pattern). But my opinion is mixed. You are doing BP removal which is desired but I am not in favor of big PRs as they need extensive testing and review. IMO, in such a bug codebase, a big PR might do more bad than good unless the review and testing is really extensive. Nevertheless, As I said removal of BP is very much wanted as a major upgrade of React and many other changes are softly dependent on it.

Yeah, I don't think it's a good idea to dive into code straight away, I'd rather have people checking all the interfaces they use daily and look at what broke in terms of layout.

I know it looks like a huge change but from what I saw we used BP just for markup, the only thing that has some kind of interactive behavior is Dialog (we lost a lot of interactive things after replacing map with a new one opening in a popup). So it should be pretty obvious if something broke by just the look of it. I'm trying to do a screen by screen comparison, but that still requires some time.

Copy link
Member

@Simon-Laux Simon-Laux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bugs from testing:

  • clicking on any page in settings just closes the dialog and does not work.

  • new group in create chat dialog has the same issue

  • clicking on contacts in group edit/view dialog also closes the dialog and does not do what it is supposed to do

  • Icons in gallery look different

Bildschirmfoto 2024-07-04 um 22 42 29 Bildschirmfoto 2024-07-04 um 22 42 53

should not be blue

  • tabs are invisible in dark theme
Bildschirmfoto 2024-07-04 um 22 44 05
  • Dialog footer items in add as second device are not aligned at the start and end.
Bildschirmfoto 2024-07-04 um 22 45 49
  • tabs in scan qr code dialog look different
Bildschirmfoto 2024-07-04 um 22 57 23

scss/_icons.scss Outdated
& > svg {
fill: #bf0000;
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was the removal of the hover effect intentional?

Copy link
Collaborator Author

@maxphilippov maxphilippov Jul 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not intentional, but I moved it to <Icon coloring in latest commit, thanks for catching this

@Simon-Laux
Copy link
Member

Simon-Laux commented Jul 4, 2024

I think we should forget about using Overlay for dialog and try to use the <dialog> element that the browser already provides, it even already has a ::backdrop css selector.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

I guess we should first try to use them with the open attribute without showModal, that we don't need to rewrite the dialog manager, but if that doesn't work we might need to rewrite it. also I wonder if the html5 dialog element supports multiple dialogs on top of each other.

If the <dialog> element doesn't work then we need to adjust the overlay component:

  • make sure the onClick handler is on the backdrop and renamed to onBackdropClick
  • make sure the overlay content is centered in a way that it does not block the backdrop from being clicked.

(thats the bug that prevents me from using the settings dialog)

@Simon-Laux Simon-Laux added refactor This PR or issue is about refactoring technical debt labels Jul 5, 2024
@farooqkz
Copy link
Collaborator

@maxphilippov after you addressed the bugs Simon has found, ping me to do a review by using.

@maxphilippov
Copy link
Collaborator Author

I think we should forget about using Overlay for dialog and try to use the <dialog> element that the browser already provides, it even already has a ::backdrop css selector. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

I guess we should first try to use them with the open attribute without showModal, that we don't need to rewrite the dialog manager, but if that doesn't work we might need to rewrite it. also I wonder if the html5 dialog element supports multiple dialogs on top of each other.

If the <dialog> element doesn't work then we need to adjust the overlay component:

  • make sure the onClick handler is on the backdrop and renamed to onBackdropClick
  • make sure the overlay content is centered in a way that it does not block the backdrop from being clicked.

(thats the bug that prevents me from using the settings dialog)
also replying to @WofWca

So I've looked into that and I personally find the very rough and actually bad to use.

I pushed a reference implementation I used to figure things out.

My biggest problem with it is the desing which is kinda orthogonal to React idea of 'you specify element visibility by its presence in the DOM'.

This one is stateful and that makes it do excessive work which we don't even use.

Our current system (and I would argue it's a sane one) has a simple principle:

  • there's no 'closed' state for dialog, if it's in DOM it's open
  1. There's only one way to open through markup and it's the only property 'open':
    that gives us neither backdrop nor 'close on escape'
    So we have to do useEffect and call showModal() every time, cause we don't have a 'closed' state.

Do we need a 'closed' state? I don't think so. That would require either to have all dialogs present in DOM or to have a manager to cleanup unused dialogs. I don't see any of these being useful.

We also need to have CSS-display: flex on the dialog, which conflicts with how manages display.

  1. We already have a stack of opened dialogs in Dialog Context and it's implemented as natural as possible with array.
    So storing it's own order is again excessive work.

What I'm doing in reference impl. is using it's onClose callback to send a message to our DialogContext it's time to delete this one right after it get's hidden.

  1. I'm not an expert on accessibility but it seems like it doesn't even set aria-modal="true"

@maxphilippov
Copy link
Collaborator Author

maxphilippov commented Jul 18, 2024

Bugs from testing:

Most of the dialog things should be fixed, but there's also a clear discrepancy between our styles. I didn't have a problem with flex dialog footer/header. But I had issues with basic text color in dialog. Can you re-check those please?

I didn't want to touch Gallery since @farooqkz is working on this, maybe we can handle it the same you @Simon-Laux did the follow-up PR to this one?

@maxphilippov maxphilippov force-pushed the maxph/blueprintjs_removal_part2 branch 2 times, most recently from 1263d2b to f9bf66d Compare July 18, 2024 12:25
@nicodh
Copy link
Contributor

nicodh commented Jul 18, 2024

@maxphilippov could you please go through the comments and answer Simons in detail (unresolved conversations)
For example which of the reported bugs are fixed.
Would be helpful for reviews...

@Simon-Laux
Copy link
Member

can you check the todo boxes in my comment for the issues that you have addressed?

@farooqkz
Copy link
Collaborator

@maxphilippov I think it's a good idea that I finish my Gallery BP removal and that you base your PR on it? Because one of the bugs @Simon-Laux has found directly is part of Gallery. Plus I'm doing some refactors there and introducing "Tabs" component which you could use.

@Simon-Laux
Copy link
Member

Simon-Laux commented Jul 18, 2024

max pr is bigger so I guess the other way around would make more sense? (rebase #3977 to this pr and change it so it should merge into maxph/blueprintjs_removal_part2)

@maxphilippov maxphilippov changed the title Maxph/blueprintjs removal blueprintjs removal Jul 24, 2024
- replace these components from blueprintjs with our own implementation
  * Overlay, Navbar, Dialog, Switch, InputGroup, FormGroup, Intent
- new icons: eye-open, eye-off

- rm blueprint import from scss
- rm blueprint from electron-builder ignorelist

- reference implementation using <dialog>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor This PR or issue is about refactoring technical debt
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants