graphile / starter

Opinionated SaaS quick-start with pre-built user account and organization system for full-stack application development in React, Node.js, GraphQL and PostgreSQL. Powered by PostGraphile, TypeScript, Apollo Client, Graphile Worker, Graphile Migrate, GraphQL Code Generator, Ant Design and Next.js
https://graphile-starter.herokuapp.com
Other
1.74k stars 219 forks source link

Remove async/await that has no effect #275

Closed caillou closed 2 years ago

caillou commented 2 years ago

Description

Remove async/await that has no effect.

Performance impact

This should not change how the code runs.

Security impact

None.

Checklist

benjie commented 2 years ago

Without the await:

In general if an await occurs inside a try block it’s probably not safe to remove, even if it’s a return await ….

caillou commented 2 years ago

Ok, I might be completely wrong here, but lookupOrganizationBySlug does not return a Promise, but void.

There is no point awaiting it.

caillou commented 2 years ago

@benjie: So I took some more time to make sure my assumptions are right.

lookupOrganizationBySlug indeed returns void and there is no point awaiting it, nor does it make sense to wrap it within a try/catch block.

It is a LazyQuery. The potential error can be found in the slugError variable.

As of now setSlugCheckIsValid is always executed before lookupOrganizationBySlug returns. No matter if you await it or not. Calling setSlugCheckIsValid sets slugLoading to true, which is why the loading indicator remains.

I have a new commit that completely removes the try/catch block. Let me know if I may open a new PR with this: https://github.com/caillou/starter/commit/de26a6f236c0dcdcd8695d07606dbf36807af392

benjie commented 2 years ago

Ah I had forgot @singingwolfboy upgraded us to Apollo v3; in v2 this method returned a promise.

This code needs totally rewriting to work in Apollo v3 for the reasons listed above - removing the async/await would just hide that there's a bug here. The code needs to be changed such that there's a useEffect hook that calls setSlugCheckIsValid(true) when the networkStatus of the useOrganizationBySlugLazyQuery indicates that the load is complete (successful or otherwise), and the entire try/catch/finally needs removing. It would also be worth looking through the rest of the code for issues like this that were missed during the v2->v3 migration. A PR making these changes would be welcome :+1:

benjie commented 2 years ago

While you're at it, turning the lint rule (I think it's @typescript-eslint/await-thenable) on that makes this kind of issue an error rather than a warning would be good so we don't hit this problem again in future migrations :sweat_smile: