-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Improve app and org loading states #16984
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
Conversation
started the job as gitpod-build-bmh-improve-org-loading-states.3 because the annotations in the pull request description changed |
@@ -13,6 +13,11 @@ export const useAnalyticsTracking = () => { | |||
|
|||
// listen and notify Segment of client-side path updates | |||
useEffect(() => { | |||
//store current path to have access to previous when path changes |
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.
Moved this into here instead of it being in the user-loader hook for some reason.
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.
Renamed this to just use-user-loader
since it doesn't deal with teams anymore. Contents also changed to wrap call in a useQuery()
.
@@ -58,3 +61,38 @@ export function OrgSettingsPage({ children }: OrgSettingsPageProps) { | |||
</PageWithSubMenu> | |||
); | |||
} | |||
|
|||
export function getTeamSettingsMenu(params: { |
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.
Moved this into here since this is where it's used.
No SSH Keys | ||
</Heading2> | ||
<Subheading className="pb-6"> | ||
<EmptyMessage |
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.
[pr-rider] 😄 - Noticed the alignment was all off here, so moved it over to use the new component for rendering these views.
Looking at this now! 👀 |
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.
That worked quite nice for me!
Also checked with a throttled connection (at 3G speed)
/hold just in case someone else is looking at it as well, and maybe testing it.
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.
Thanks, @selfcontained! 🌮 🌮
Left a few minor non-blocking UX comments. We can also merge this and improve the UX later.
Let me know what you think. 🏓
// Wait 3 seconds before showing the loading screen to avoid flashing it too quickly | ||
<Delayed wait={3000}> | ||
<div className="flex flex-col justify-center items-center w-full h-screen space-y-4"> | ||
<img src={gitpodIcon} alt="Gitpod's logo" className={"h-16 flex-shrink-0 animate-bounce"} /> |
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.
issue: Re-using the bouncing logo could frustrate or confuse users as they usually to see that loading state (bouncing logo) a lot while opening workspaces. Could be worth using something different, as the designs included in #16803. Thoughts?
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.
Ah good point. I could also remove the animation, definitely don't want user's to get confused. I mentioned it below, but I think the small little loading spinner is quite easy to not notice by itself. Would love some personality injected into the product here too 😄
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.
DEAL—Opened #17044 to keep track of the proposal to improve the full-page loading.
type Props = { | ||
wait?: number; | ||
}; | ||
export const Delayed: FC<Props> = ({ wait = 1000, children }) => { |
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.
suggestion: Not sure if this is the best line to comment about this or if this is already implementing the following: Ideally, we would wait a second or two before showing the full-page loading indicator to avoid having spinners or loading states everywhere. 💡
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.
Yup, I think the same thing. This component is built so we can use it for those loading indicators too, and just wrap them with this. We can do it in the components themselves so we get it for free everywhere..
return <></>; | ||
return ( | ||
// Wait 3 seconds before showing the loading screen to avoid flashing it too quickly | ||
<Delayed wait={3000}> |
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.
question: 3 seconds can make the dashboard still feel unresponsive, no? Could it be better to make this 1 or 2 seconds?
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.
Lets try 2. I want to avoid it flashing too quickly, 1 second is pretty easy to bump into even w/ a good connection if there's 1 slow call.
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.
DEAL 🤝
<Delayed wait={3000}> | ||
<div className="flex flex-col justify-center items-center w-full h-screen space-y-4"> | ||
<img src={gitpodIcon} alt="Gitpod's logo" className={"h-16 flex-shrink-0 animate-bounce"} /> | ||
<Heading3>Just getting a few more things ready</Heading3> |
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.
suggestion: I like the playful message, but what do you think of going with something simpler and less verbose, like a spinner with no text, using the Loader
component?
BEFORE | AFTER |
---|---|
![]() |
![]() |
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.
I'd love something that has some personality to it. Also, that small loading spinner is so easy to miss, I don't even realize it's there. Ideally most people don't see this, but for those that do, it'd be great to brighten the experience a little w/ something that could make them smile.
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.
I think we could improve this in a followup once we find something actionable.
IMO the PR is already a biiig improvement over the status quo 😉
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.
I'll drop the bouncing animation for now to reduce the chance of confusion w/ the workspace start flow, and we can follow up w/ any design/copy updates.
<div className="flex flex-col justify-center items-center w-full h-screen space-y-4"> | ||
<img src={gitpodIcon} alt="Gitpod's logo" className={"h-16 flex-shrink-0 animate-bounce"} /> | ||
<Heading3>Just getting a few more things ready</Heading3> | ||
<Subheading>hang in there...</Subheading> |
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.
suggestion: If we're keeping the loading message, I'd go with something less verbose and drop the heading above, as this page does not need it.
const client = new QueryClient(); | ||
const client = new QueryClient({ | ||
queryCache: new QueryCache({ | ||
// log any errors our queries throw |
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.
💡
|
||
export interface OrgSettingsPageProps { | ||
children: React.ReactNode; | ||
} | ||
|
||
export function OrgSettingsPage({ children }: OrgSettingsPageProps) { | ||
const org = useCurrentOrg(); | ||
const orgBillingMode = useOrgBillingMode(); |
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.
Just wondered if there are any (potential) downsides to splitting this kind of information/API wise: I imagine this way org
and orgBillingMode
could be out of sync for some render cycles, right? 🤔
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.
Or is it guaranteed that this is guarded by line 42 below (the isLoading checks)?
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.
The loading check will make sure we don't render the UI before we've gotten the org billing mode back. Is there something else you're referring to w/ the org and the billing mode being out of sync?
As an aside, It should also be cheaper to keep the org billing mode up to date if we mutate it now and need to reload it, as we won't have to update every org, and every org's billing mode anymore.
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.
(just a curious question, I don't think we should do anytime about it!)
Got some questions just to make sure I understand the trade-offs. Besides: LGTM, and works nicely as far as I tested! ✔️ |
/unhold |
Description
Addresses a few things that deal with app loading state, and org loading.
useOrganizations()
query and swap touseOrgBillingMode()
query where it was used. This removes having to load every orgs billing mode as a blocking path for the app rendering.UserContext.billingMode
in favor ofuserUserBillingMode()
query<AppLoading/>
that shows up if app takes longer than 3 seconds to load.Related Issue(s)
Fixes #16803
How to test
Release Notes
Documentation
Build Options:
Run the build with werft instead of GHA
Run Leeway with
--dont-test
Publish Options
Installer Options
Add desired feature flags to the end of the line above, space separated
Preview Environment Options:
If enabled this will build
install/preview
If enabled this will create the environment on GCE infra
Valid options are
all
,workspace
,webapp
,ide
,jetbrains
,vscode
,ssh