-
Notifications
You must be signed in to change notification settings - Fork 149
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
fix: allow users access all accounts in account switcher #5171
Conversation
pete-watters
commented
Apr 5, 2024
•
edited by leather-bot
Loading
edited by leather-bot
8fc2f6f
to
c6a599b
Compare
c6a599b
to
34f078d
Compare
5db7626
to
1a970b6
Compare
1a970b6
to
ab7af8c
Compare
ab7af8c
to
d507b50
Compare
|
||
type VirtuosoVariants = 'footer' | 'no-footer' | 'popup'; | ||
|
||
export function useGetVirtuosoHeight(accountNum: number, variant: VirtuosoVariants) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is named/located as thought it's a generic virtuoso list height function. But it isn't, because the first argument is specific to the accounts list, one particular instance of it.
Isn't this a coupling of unrelated concerns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still inflight but when needed I can refactor accountNum
to be data array.
We use Virtuoso
in 3 areas and all of them relate to rendering of accounts lists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use Virtuoso in 3 areas and all of them relate to rendering of accounts lists
If you'll allow me to rebuttal this: the fact that the virtual lists we use currently relate to account lists, isn't reason enough to presume all future virtual lists are going to relate to account lists.
This code (if only conceptually) couples together a generic virtual list function with a specific type of data (accounts). I think that's a dangerous assumption, and one that breaks the single responsibility principal.
I imagine this situation: another developer is tasked with building an expensive list to render. They need to use this virtuoso function to get the height, and end up being hampered/confused by the fact there's account-specific in there, that they don't need or want.
What are your thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps I didn't communicate effectively previously but I will be changing this code and updating the variable names. The work is not finished yet and I'm unsure if this code will be needed, ideally not. That's why I posted it as a draft. I am trying to first fix the bug, then refactor it to be better.
I agree totally with you and I don't want to break the single responsibility principle. It doesn't make sense to couple this to accounts at all. At this point its just the name I was using as the data is accounts and I am focusing on the UI bugs.
Once thats fixed I will update the code to make it clean and reusable for the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Virtuoso is supposed to support dynamic heights. Did you figure out doing this why it doesn't work? Is it specific to the dialog component? It'd be great if this worked, and we didn't need a complicated height-setting hook
It would be definitely better to not need this at all. I'll keep trying using their docs. In their examples they give It has been complex as we want a want a dynamic height We have always seemed to have this issue with users either not being able to select the last account or else accounts in the list spilling out of the dialog. Here's an idea of some of the problems: Ideally we would have no need for a hook at all and it would just:
|