Jump to content
Search Community

TypeScript and auto import (with IntelliJ IDE) in V3

jash test
Moderator Tag

Recommended Posts

Hey and congrats to the V3 release!

 

I'm using TypeScript with IntelliJ IDE, which has a fabulous support for auto importing of classes. I was in big hope that your will release "native" TypeDefinitions (which you did!), that will boost my workflow as i know from other libraries. This means, that you do not have to manually write each time import {gsap} from "gsap" by yourself, but that this import statement is managed/added automatically, when writing gsap.to...  

 

But sadly, it doesn't work. I still have to add this import statement by myself every time I use gsap. I added 3 screenshots to get this problem more visualized. You see, that all gsap related objects/classes are unknown to the IDE (but they should cause of the TypeDefinitions), but other library objects are known and a correct import statement is suggested (or added automatically).

 

Also, adding the d.ts files to the tsconfig.ts doesn't solve that problem. It removes the error in the IDE, but it throws a compile time error, because the import is still missing.

 

If it helps, I can create a little example of an IntelliJ project.

 

Best regards

 

Matthias

known import statement.png

gsap unknown import statement.png

Sine unknown import statement.png

Link to comment
Share on other sites

I'm guessing it is like that for several reasons.  GSAP can be imported from several different locations, so which one is it supposed to use? The first choice is the most common, but there are reasons you might import from one of the other locations.

 

import { gsap } from "gsap";
import { gsap } from "gsap/all";
import { gsap } from "gsap/gsap-core";
import { gsap } from "gsap/src";
import { gsap } from "gsap/src/gsap-core";
import { gsap } from "gsap/src/all";
import { gsap } from "gsap/dist/gsap";

 

And it might be like that because the definitions are designed to work globally, which is intentional for several reasons.

 

The first is so that definitions will work for people who don't use modules, or use JavaScript. See how it works in a regular JavaScript file with no imports. A lot of people still use regular script tags.

 

Annotation 2019-11-14 002709.png

 

 

The second is because everything can be made global with this line of code, and there is no way to conditionally make everything global in the definitions.

 

gsap.install(window);

 

My suggestion would be to create an import snippet. Maybe even a custom one just for gsap.

 

And you don't have to import eases. Just use the new string syntax.

 

ease: "sine.inOut"

https://greensock.com/docs/v3/Eases

 

 

  • Like 3
Link to comment
Share on other sites

Thanks for your quick and detailed answer. To make gsap globally is a handy solution, but it breaks a bit of a module bases approach of bundling only requires modules via imports. But you know gsap is always needed ;)

 

Currently I'm not sure if I prefer string based easing definitions. It is easy to make mistakes (misspelling) and you need to know how exactly the ease is named. If you work in a typed environment with intelligent code completion it is much more easy, self-explaining and safer to use static classes (likeSine.easeOut) to define the ease of a tween. All mistakes will be visible in the IDE or at least during compilation. 

Link to comment
Share on other sites

20 minutes ago, jash said:

Currently I'm not sure if I prefer string based easing definitions. It is easy to make mistakes (misspelling) and you need to know how exactly the ease is named.

You're welcome to use whichever you'd prefer, but for me and most people I think the string based names become preferable once you get used to it. The naming convention is much simpler - things like Elastic.easeOut.config(1, 0.3) become just "elastic(1, 0.3)" for example. True intelligent code completion is more difficult but the hassle that it saves you from having to import things correctly outweighs it IMO.

  • Like 2
Link to comment
Share on other sites

27 minutes ago, jash said:

but it breaks a bit of a module bases approach

 

I understand that, but not everyone who uses the definitions will be using modules. And almost all of the @types definitions use the same approach with globals & modules.

 

27 minutes ago, jash said:

Currently I'm not sure if I prefer string based easing definitions. It is easy to make mistakes (misspelling) and you need to know how exactly the ease is named.

 

I was against strings at first, but I like them better now because they are shorter, don't require imports, and are consistent with custom easings. The misspelling is a minor issue IMO as it should be noticeable if an ease isn't working. 

 

// Create once
CustomEase.create("foo", "...");
gsap.registerEase("bar", i => i);

// Use in any file
gsap.to(obj, { x: 100, ease: "foo" });
gsap.to(obj, { y: 100, ease: "bar" });

 

 

  • Like 4
Link to comment
Share on other sites

I came up with following solution to not manage gsap imports manually. Ok you have to do it one time only ... And if you don't need Animate anywhere in your code, there should be no gsap codebase in your compiled js file.

 

import {gsap} from "gsap";

export class Animate {

    static to(targets: gsap.TweenTarget, vars: gsap.TweenVars): gsap.core.Tween {
        return gsap.to(targets, vars);
    }
    
    // ... wrap other gsap-methodes like above if needed

}

Then you can use it like gsap, but your import of Animate should be done by IntelliJ automatically:

import {Animate} from "Animate";
Animate.to(myElement, {
  x: 100
})

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...