`blitz console` is slow to load - switch to esbuild loader about blitz HOT 12 CLOSED

Tried replicating this on Mac OS Catalina 10.15.6, but it worked without any perceivable delay.

Here is sc of the time taken for each module:

I know these times would vary between PCs and OS. Maybe it would be good to add a loading indicator when it is loading these modules. Let me know what you think @flybayer.

from blitz.

@JoseRFelix thanks for investigating! This is definitely WAY better in the latest blitz canary. That said, I'm still noticing a 1-3s delay on my project which has a good bit more modules than what you listed here.

I still think we should lazy load these, because as apps get bigger, this will get worse, no matter how optimized it is.

from blitz.

So, I've been thinking about some possible solutions:

1. Have a loading indicator while all the modules are loading, and show input when done. This will make the user have to wait before he can use the console. It is not probably the best solution, but it is the fastest to develop.
2. Have a command that lists the files' names of all available mutations, queries, jobs, integrations, and utils file names. Then, the user will require what he needs just like in javascript, using another command. This would solve the problem but it would increase the learning curve and have the user requiring the files every time.
3. Read the user's input and try to import the files automatically with the same function name as provided in the input. In an ideal world, the user will name the function the same as the default export, otherwise, a wrong import would be made. Also, utils can house a file with several functions whose name won't share the file name.
4. Require files by domain. The user with a command will be able to import all queries and mutations from a specific domain like tasks or projects.

In my opinion, I would prefer to have the first option since all modules will be available on the get-go.

from blitz.

Isn't it possible to keep what we have no (load everything), but set proxy objects in the repl context and when the proxy is accessed, load the requested module at that time.

So by default getProjects for example is set on the repl context just like now, but instead of having a references to the actual module, it's a proxy object that when accessed will load the module.

Make sense?

from blitz.

Yes, it is possible! The only thing to think about is how the script will know which file to import. This can work fine if we had the same file name and a single function per file. However, users can change the function name or have several functions that won't match the file name.

Maybe, we could store every function name and validate it in the proxy.

from blitz.

Yeah, but we have that same issue already, right? (you are right that we need to resolve that somehow)

from blitz.

I'd say it could be a little bit faster than our current approach since we wouldn't be doing a full import. However, we still would have read the file to get every function name and search our object if it contains the function.

from blitz.

Ok, if you want you can work on this and just figure out what makes the most sense to do.

from blitz.

Sure! 🚀

from blitz.

@JoseRFelix I discovered that the console is quite fast when running the local blitz dev version, but it's still extremely slow when using off npm

from blitz.

So I think a good solution is to use esbuild. Perhaps with https://github.com/egoist/esbuild-register or https://github.com/folke/esbuild-runner.

I tried doing setting that up briefly. It certainly has potential but we need ability to provide custom esbuild options for things like setting externals. So we need to PR this ability to one of the above projects or use a custom fork.

Adding the "register" statement in our code is simple, same as we are currently doing with ts-node: https://github.com/blitz-js/blitz/blob/canary/packages/cli/src/utils/setup-ts-node.ts#L8

Note: one thing that's important is that this uses baseUrl and path aliases from both tsconfig.json and jsconfig.json

from blitz.

So I gather that these are examples of runners/watchers for development mode. For using a bit of esbuild to build in production, to get ~2x build speedup with NextJS, try esbuild-loader-examples.

from blitz.