Open hasparus opened 5 years ago
I'm glad you like it!
I'm worried to hear that; I was very worried the performance would sputter when I was working on it, but I didn't have any problems on my dinky old MacBook Air so I figured it was fine. Could it possibly be something else? If you sent me a minimal repo that's laggy for you, I'd take a look at it.
However if you do want to have a smaller depth file, then you should just have to
cd node_modules/shades/lens-gen;
npx bower install;
npx pulp main -- -n=N
N=4 would probably be a good depth; it's only 340 overloads per function as opposed to 5,460.
If more people want this and 4 turns out to be a good number, I could include that shorter file in the repo so you'd have the option to do:
import { get, mod, matching } from 'shades/tiny'
I didn't notice any problems in an empty TS project with shades as the only dependency, but I managed to get stuck on loading a few times just pasting examples from README into a fresh NextJS project.
Here's the link -- https://github.com/hasparus/repro--shades-ts-lag/blob/master/pages/index.tsx.
Weird. After a brief boot up, I saw very fast performance and accurate bug-checking on everything, even on this dinky old laptop.
The only thing I did change was switching on
"strict": true
in the tsconfig.json
. A bunch of things behave badly without that, so maybe that could help?
If not, try the depth 4 typings and see if that fixes it. We can take it from there.
Thanks so much! I have strict: true in the closed source project. I forgot to turn it on in the repro.
Using depth 4 typings solves the problem for me.
On Fri, 6 Sep 2019 at 01:14, James McNamara notifications@github.com wrote:
Weird. After a brief boot up, I saw very fast performance and accurate bug-checking on everything, even on this dinky old laptop.
The only thing I did change was switching on
"strict": true
in the tsconfig.json. A bunch of things behave badly without that, so maybe that could help?
If not, try the depth 4 typings and see if that fixes it. We can take it from there.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesmcnamara/shades/issues/31?email_source=notifications&email_token=ADU7HZUJOQPGFQIOQD5ETC3QIGHG3A5CNFSM4ITDPE3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6BHA5I#issuecomment-528642165, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU7HZXJGHHM57GMNXHYUX3QIGHG3ANCNFSM4ITDPE3A .
I suppose we can close the issue and wait to see if somebody else has the same problem. Thank you for your help and effort :)
On Fri, 6 Sep 2019 at 06:50, Piotr Monwid-Olechnowicz hasparus@gmail.com wrote:
Thanks so much! I have strict: true in the closed source project. I forgot to turn it on in the repro.
Using depth 4 typings solves the problem for me.
On Fri, 6 Sep 2019 at 01:14, James McNamara notifications@github.com wrote:
Weird. After a brief boot up, I saw very fast performance and accurate bug-checking on everything, even on this dinky old laptop.
The only thing I did change was switching on
"strict": true
in the tsconfig.json. A bunch of things behave badly without that, so maybe that could help?
If not, try the depth 4 typings and see if that fixes it. We can take it from there.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jamesmcnamara/shades/issues/31?email_source=notifications&email_token=ADU7HZUJOQPGFQIOQD5ETC3QIGHG3A5CNFSM4ITDPE3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6BHA5I#issuecomment-528642165, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU7HZXJGHHM57GMNXHYUX3QIGHG3ANCNFSM4ITDPE3A .
Sounds good :)
I'm running into this problem as well.
@hath995 I would encourage you to try creating a minimal repro that has lag. Like I say; I run this on a 6 year old MacBook Air without any trouble, so my instinct is that there is something else at play.
But I am open to creating a smaller set of typings that can be used for limited environments.
I am using a 2018 macbook pro so it would seem like it should be fast enough, but it basically locks up vs-code while it thinks about the types. I used your suggestion about and replaced my file with npx pulp main -- -n=4 and it became tolerable.
Have you tried starting a new project, installing shades, and trying it there?
You could just toss this into a file in a new project and test it's speed:
import { get, set, mod } from 'shades'
interface Post {
title: string;
description: string;
likes: number;
}
interface User {
name: string;
posts: Post[];
goldMember: boolean;
friends: User[];
bestFriend?: User;
}
declare const users: User[];
declare const user: User;
declare const byName: { [name: string]: User };
Seems ok using that example you pasted. In tsconfig turned on libs ["dom","es2017","esnext"] and then it seemed to slow down the type resolution quite a bit, probably like 5 seconds before it resolved that something was a user.
let test = set("posts", 0, "likes")(2)(user);
Do you have "strict": true
on?
It is, yes.
Alright. I will try to publish a version of this library with smaller bindings ASAP, and I'll keep you posted.
I think Variadic Tuple Types coming in TS4 should help, or maybe be able to eliminate all the overloading.
I love the shades API! I don’t have anything extremely useful to add, but just wanted to +1 that I also noticed my IDE and MacBook Pro (2018, 16G RAM) struggled with inferring types the moment I added some shades-based code - I’m using TypeScript 4.6 with strict mode. I’ll update here if I can narrow it down to a reproducible set for you. Unfortunately I haven’t been able to work with it long enough before my IDE runs out of memory!
For the record, variadic tuple types was not the miracle I was hoping for 😬. One of the reasons why shades is so awesome IMO is how flexible it is. Encoding the flexibility into the type system is clearly not straightforward. Or rather, I suppose it is straightforward, also just extremely verbose.
First of all, I wanted to say that
shades
is really cool and has very nice public API.You're generating overloads with PureScript and that's pretty awesome in my opinion, but my VSCode seems to disagree. Tooltips and code completion start to get laggy.
Did you have any trouble with text editors with generated typings? I'm thinking about generating overloads with smaller depth and using patch-package to substitute generated typings as a workaround.