Exposing GWT components based on Elemental2 to TypeScript ?

[DavidN]

I'm currently investigating how to expose a GWT based component (that uses JsInterop and Elemental2) to JavaScript and TypeScript.

The goal is that this component should be reusable in an Angular 4 application, but also in GWT applications.

I'm finding it really hard to create a .d.ts file that is acceptable to Angular 4 (documentation and reality seem to clash).

I was wondering, am I the first to try this ? 

For now I gave up on the attempt to declare a proper .d.ts file and just declared the reference as any.

But somehow I think it would be nice if GWT had a linker that could actually output that TypeScript file automatically saving me from doing double work.

I am using the sso-linker in GWT to get all my JsType classes exported and I just load the generated nocache.js file.

Is there a way to make sure that the contents of that file does not cache with other JS objects ? 

Can I somehow declare at compile time what I want to have exported ? There seems to be more in the output than what I actually need (I don't need an EntryPoint for example).

[Thomas Broyer]

On Tuesday, October 10, 2017 at 5:12:51 PM UTC+2, DavidN wrote:

I'm currently investigating how to expose a GWT based component (that uses JsInterop and Elemental2) to JavaScript and TypeScript.

The goal is that this component should be reusable in an Angular 4 application, but also in GWT applications.

I think you'll be delighted by J2Cl when available, and then use Clutz and/or Gents (https://github.com/angular/clutz) for TypeScript interop (see also https://github.com/material-components/material-components-web/issues/134 )

I'm finding it really hard to create a .d.ts file that is acceptable to Angular 4 (documentation and reality seem to clash).

I was wondering, am I the first to try this ? 

For now I gave up on the attempt to declare a proper .d.ts file and just declared the reference as any.

But somehow I think it would be nice if GWT had a linker that could actually output that TypeScript file automatically saving me from doing double work.

You could possibly use an annotation processor to do that (processing all jsinterop.annotations.* annotations)

 

I am using the sso-linker in GWT to get all my JsType classes exported and I just load the generated nocache.js file.

Is there a way to make sure that the contents of that file does not cache with other JS objects ? 

Can I somehow declare at compile time what I want to have exported ?

Yes, through -includeJsInteropExports and -excludeJsInteropExports patterns (added in 2.8.1)

There seems to be more in the output than what I actually need (I don't need an EntryPoint for example).

The entry point is required in GWT, but can be empty / no-op if you export JsInterop types.

[David]

Is there any tentative release date for j2cl ? I was not present at the GWTCon, maybe it was mentioned there ? Or is it the typical “It will be released when it is ready” approach ?

Thanks for the links.

I must say that I kinda hate TypeScript and I prefer Java and GWT. But hey, other people seem to have a different opinion.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Wednesday, October 11, 2017 at 10:43:06 AM UTC+2, DavidN wrote:

Is there any tentative release date for j2cl ? I was not present at the GWTCon, maybe it was mentioned there ? Or is it the typical “It will be released when it is ready” approach ?

It's a Google project, so we'd have to ask Google. But the idea was that it'd be opensourced once it's more stable and really usable; and there's work needed on the build: the build files are currently Blaze-specific (Google's internal build system), and either they'd have to make them Bazel-compatible, or someone else would have to come up with another build tool (Maven or Gradle); and after building it, there's the question of distributing it (into Maven repos), which also somewhat depends on the build tool. The idea is that it shouldn't generate too much frustration for all of you (and us) who are eagerly waiting for it, so it cannot just be a "code drop" that you couldn't even build and run.

[David]

Yes indeed, JsInterop and Elemental2 are really the building stones of what we can do in the future. So there is already a lot that can be done before J2CL is released and integrated. 

I think it is a good idea that all the components that might be migrated are indeed modernized. When I see how templating or routing is done in Vue.js/React I wonder if GWT should not completely revisit its architecture.

 

On Fri, Oct 13, 2017 at 3:23 PM Colin Alworth <nilo...@gmail.com> wrote:

The other aspect is the rest of the ecosystem - what is GWT without Widget/elemental/errai, without the various mvp/c tools, etc?

JsInterop works in J2CL, in nearly exactly the same way as GWT2. All existing JRE emulation in GWT2 also already works. From here, we can start building tools, starting with elemental2, and GWT-compatible annotation processors (like dagger2 instead of Gin).

The work that remains is not just making J2CL and the Closure compiler into a complete set of tooling (which works not only from the command line, but from the supported build tools and IDEs, with all of the expected sourcemap support, etc), but also in making sure that once those tools are ready, that other pieces are ready too. Some aspects of GWT2 like Activities, and the EventBus, are already compatible (though Thomas Broyer went ahead and modernized Event/EventBus further, as may be appropriate for other components), while others like animations, editors, uibinder, rpc, validation, internationalization, etc are all still in varying states of migration to JsInterop and annotation processors, most unstarted.

Some of these are harder than others - I am inventorying work already done and trying to get a very rough outline of remaining work to do, and hope to publish this in about a week. Fnding owners for each unit of work will be important, at least for any tool we hope to still use in GWT3.

[Colin Alworth]

There is a nearly-gwt3-ready vue-gwt library at https://github.com/Axellience/vue-gwt if you'd like to see how that could feel - knowing the author, he wouldn't mind feedback, or even a competing implementation to try thinking differently if you have another direction to try.

Personally, while the templating seems interesting to me (as long as design goals are specified up front, to avoid turning into "oh, its just HTML, with code in it!" like JSP...), the routing and "state" management seems a bit off for my tastes. I'm not prepared to defend this opinion too vigorously though, I have more research to do.

Updated MVP tools will be important, and a few people talked about prototypes in varying stages of completion at the conference, many already using current best practices.

Remember, GWT's architecture is mostly just "maintain a great compiler" - the widgets and other tools mostly came about as a way to deal with the horrible mess that browsers were up until the last 1-3 years. The coming reorganization that will push the "user" library out into their own separate dependencies will help make this clearer to users - using GWT does not mean using Places, or RequestBuilder, or Widget.

--

  Colin Alworth

  co...@colinalworth.com