Slow Intellisense using VSCode on large Typescript Project
Hi everyone,
I've been using Xata for ~2 months now on a Sveltekit+Typescript Project as my main DB. Overall I'm very happy and love the SDK!
As my project is getting increasingly large (~10k lines of code + 30 dependencies/packages) I noticed that the Intellisense for the Xata SDK is slowing down.
E.g. it takes up to 15 seconds for inline suggestions and "go to definition". This is really slowing down my productivity.
I already tried disabling Extensions, which made it a little better, but Intellisense is still pretty slow. I already looked into Stackoverflow and other resources, trying to mitigate potential Typescript/VSCode issues.
I'm pretty lost. Did anyone experience something similar? Could this be a Xata-specific issue? Any help appreciated 🙂
15 Replies
Hey @Rick182 , I'm excited to read that your project has grown by much!
Can you clarify a couple things so we can look into it: which version of the Xata SDK are you currently using?
Does the issue with slow suggestions surface in all places, or could it be that it specifically affects nested types beyond the first couple levels? (such as one.two.three and beyond)
Here is some background on why I'm asking this:
Some previous versions of the Typescript SDK computed types with deep recursion. That is, including "loops" when one table links to another links to another ... links back to the origin table and so on. So complex schemas that have such loops makes the types computation expensive and in some cases the IDE freezes. In order to mitigate that, we set a limit at 3 levels of recursion for computing types with the release 0.26.8 (https://github.com/xataio/client-ts/blob/main/packages/client/CHANGELOG.md#0268). The downside to that is that types won't be computed beyond that depth. We added a note for it in the limitations docs here: https://xata.io/docs/sdk/typescript/overview#limitations.
That said, if you noticed the issue affects mainly deep nested columns, can you check if this still occurs with the latest version?
Hi @kostas thank you for the quick response!
I'm using the current version (0.26.9) and it seems like the problem occurs in all places.
Some info that may be useful:
I added some additional abstraction to my codebase because I thought it would increase maintainability. However, this might also contribute to the issue.
I have a custom, separate class for each table in my DB. In these classes, more complex CRUD-based functions are defined.
All classes are instantiated once and included in a singleton decorator class (single entry-point to all DB-operations).
I also defined a lot of custom types/interfaces that wrap around XataRecords which make it easier to check if certain attributes could be nullish.
I think this might be a VSCode+Typescript problem because sometimes "go to definition" also takes ages when I try to go to custom DB-code I wrote...
I see. A quick way to narrow down whether it is related to Xata types or it has to do with something outside that, is to try a "vanilla" (new/empty) project where you just import your Xata client and simply try writing up some xata sdk calls and check how that behaves. If intellisense works fast on that, it indicates there's something "outside" of the Xata SDK (probably more generic Typescript-on-VSCode due to class layering) going on.
@kostas I came across
Type instantiation is excessively deep and possibly infinite. for this code:
Is the deep-recursion-protection not working as expected here? This line is affected in particular: summaries: { total: { count: '*' } },.
If relevant: allFilters is an array of ~10 different $all's and $any's.Interesting, does this still occur even if you remove the parameters
filter and columns? Also which version of the TS SDK are you using?Recompiling... 🥱
Still the same error. I'm on version 0.26.9
Thank you, I think the best way for us to investigate is to try reproduce using your schema. Could you share it? (
xata schema dump from the CLI). In case you don't want to put it here publicly, you can send it to support@xata.io or submit a ticket on our portal: https://support.xata.io/hc/en-us/requests/newSent a mail 👍
We will check it, thank you!
Unknown User•6mo ago
Message Not Public
Sign In & Join Server To View
Schemas with "circular" relations, meaning tables with links to other tables which, one or more steps later link back to the origin table, tend to generate expensive recursive type computations. Each nested level adds a bigger amount of compute to the type checker and the LSP.
The client dev team limited type recursion to 3 levels (https://github.com/xataio/client-ts/pull/1222/files) because beyond that, IDEs could even crash with such large recursive schemas.
The best advice I can give is to review and simplify the schema that causes this, to avoid recursive relations as much as possible
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
The simplest way to avoid this is to put a // @ts-ignore before the line that causes the TS error, which will simply avoid the type computation.
The Xata SDK stops computing types at 3 levels of link recursion (including circular links such as between user and merchant), however in tables with many columns, 3 passes can still generate big enough types to slow down the IDE and make TS compiler warn that there's possibly an infinite number of types.
An alternative approach would be to switch to doing relations with SQL (i.e. use the SQL overHTTP endpoint xata.sql https://xata.io/docs/sdk/sql/overview) and use JOIN instead of xata links.
Another option is to use the Kysely integration for typed results generated with SQL relations: https://xata.io/docs/sdk/get#multiple-relationship-records-per-table
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
Happy to help! I understand the requirements to stick close to the SDK when possible. SQL however unlocks more flexibility so don't hesitate to try it - actually some relational statements are possible with SQL only.