-
In my former GWT project we used @JSType-annotaded classes to access the java-coded business logic from a TypeScript-project (instantiating, calling methods on it). After migrating to j2cl I cannot see any of the JSTyped-classes. If my understanding is correct they are only visible until closure compiler comes to action. Am I right with this? Case if, what's the best practise to make the types survive the compiler? Plan is to have JS-Files to include in my webapp that make the types available to be used from JS/TS. Thanks for any help |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments
-
I was able to make some progress with goog.exportSymbol and goog.exportProperty but I'd like to have all the explicit @JSType-d types available automatically. Maybe there's a compiler flag? |
Beta Was this translation helpful? Give feedback.
-
What most of our users do run the closure compiler on all of the code (from J2CL, TS, JS). That way the whole application is optimized together. |
Beta Was this translation helpful? Give feedback.
-
The open source GWT/J2CL community (https://gitter.im/gwtproject/gwt and https://gitter.im/vertispan/j2cl) is discussing an annotation processor that will generate exportSymbol and other calls so that closure emits the expected code, along with some other tools such as to make it easier to access es6 modules, etc. We've found that generating a .native.js file works for this, or if one already exists, a new plain .js file can also export it correctly, but generally agree that this doesn't belong in J2CL itself (either as I described in .js inputs, or in closure flags). The only way it makes sense to me to have it in J2CL is if it is possible to deliberate emit some closure jsdoc annotations like |
Beta Was this translation helpful? Give feedback.
-
Ok, that matches my observations. So I‘ll try my luck with a custom annotation processor for the jstypes of my project. I don‘t think that I need the „big“ approach here. Thanks for all the clarification. Now I do see the difficulties providing a sufficient GWT replacement on top of J2CL. |
Beta Was this translation helpful? Give feedback.
-
@niloc132 keep in mind that letting libraries decide what to export is problematic and if you generate goog.export with native.js that will be the result. |
Beta Was this translation helpful? Give feedback.
-
Strongly agreed, this is not optimal, as you end up with unoptimizable code, bigger stuff elsewhere (This is one of my gripes about web components...). This is one of the reasons i'm working to get es6 modules seamlessly working with j2cl output so closure can process them all together. That said, one of the main premises of the npm is that you get the already-packed file and webpack or whatnot will just combine all the files, do some simple treeshaking, not recompile each library on its own (or the whole world). I have seen lots of projects using closure output in the form of a library, but rarely ("never" would more accurately reflect my experience) do they take more than one closure-compiled dependency and re-compile it with just the required entrypoints, exports, etc. |
Beta Was this translation helpful? Give feedback.
-
@niloc132 Can you elaborate on how
works? I have some web components that are being elided. I'm new to using J2CL, not even sure yet where the documentation for |
Beta Was this translation helpful? Give feedback.
-
I'm new to J2CL and have the same demand that to access the java-coded business logic from a TypeScript-project. After some work around I find there's one thing called For example, the
Then after imported the Am I right? |
Beta Was this translation helpful? Give feedback.
-
Yes, that's correct. You can see the the |
Beta Was this translation helpful? Give feedback.
Yes, that's correct. You can see the the
goog.exportSymbol
documentation here for more examples:https://google.github.io/closure-library/api/goog.html