Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Colin Alworth
    @niloc132
    (one final note @ckemmler, as i'm trying to shut up and let you eventually catch up: ) i see from your github profile that you are using gwt-vue - adrien baron was heavily involved in the early steps with j2cl, and i believe produced the first repo that i didn't write in the open source world which could run with j2cl, so any work invested in that tooling is likely already j2cl-compatible
    Candide Kemmler
    @ckemmler

    Thank you @niloc132. I will try to follow Google's guidelines. That said, it is still not clear how I would just refactor all my native methods from JSNI to JsInterop (I don't understand why there is nowhere a simple tutorial on how to do that – maybe I'll do it when I have figured it out). I'm not clear either on what a 'generator' is, or better: how to know if a library has one.
    FTR, here's what we are using (so far):

    • com.google.gwt.user.User
    • com.google.gwt.query.Query
    • com.google.web.bindery.event.EventBinder
    • com.axellience.vuegwt.VueGWT
    • com.axellience.vueroutergwt.VueRouterGwt
    • com.google.gwt.i18n.CldrLocales
    • dagger.Dagger

    I'm still wondering if there is any chance that I can seamlessly move to a more recent GWT release (given I got rid of all the JSNI code I have written so far). And if so, how I would proceed to do that (again, no tutorial or general instructions about that). I'm still not clear where the 'new' GWT lives. Is it in the GWTproject repository? Or else: does "upgrading to gwt3" actually means "use j2cl and add various JSNI-free GWT modules to your project"?

    Thank you again. The fog is slowly dissipating, but things are still rather misty.

    Colin Alworth
    @niloc132

    simplest "upgrade to gwt3" path that we've outlined:

    • incrementally replace all com.google.gwt in your project with the corresponding org.gwtproject, as it is released
    • replace your own written jsni/generators with something updated

    at this point you should be nearly compatible with both compilers, plus or minus a few "magic methods" (the technical term, believe it or not, for some specialized methods in gwt2, like GWT.create, GWT.isClient(), etc). very few code changes at this point should be required to finish the transition to j2cl, mostly just build setup to make sure everything works

    please note that this assumes your project structure is client/shared/server, rather than a single monolithic project containing code for client and server in one single classpath
    dagger already works great on j2cl, i don't know about eventbinder, and i'm not sure about Query - where do you get that dependency from?
    vue of course is fine, and User is nearly ready (cldr locales is part of gwt-i18n and is still proving a bit time consuming)
    Colin Alworth
    @niloc132
    do note that replacing your com.google.gwt dependencies is likely to have some small breaking changes: at the very least, any GWT.create(...) will be replaced with something like new MyWhateverClass_Impl(); - like you do in dagger2
    Candide Kemmler
    @ckemmler
    Great, that's great... Thank you.
    Colin Alworth
    @niloc132
    oh right - i thought it was called GQuery
    i know of no one who has looked into it yet, but gwtproject.org itself uses it, so we should take a look
    Candide Kemmler
    @ckemmler
    Oh and we're also using GWT-RPC...
    Colin Alworth
    @niloc132
    eventbinder: that will require a rewrite with annotation processors
    yes, gwt-rpc is 80%+ ported, depending on your interpretation, and i'm using it in production now actually
    Candide Kemmler
    @ckemmler
    Great
    Colin Alworth
    @niloc132
    it still doesnt let you write two different interfaces, one sync and one async, but my primary use case was websockets, so we only wanted async
    a very tiny bit of codegen has to be added to let you author both interfaces
    there are also open issues
    Paul Sitarz
    @PaulSitarz
    @niloc132 Hi Colin, I am now working on porting my widget library XGL (https://www.xalys.com) to j2cl. The lack of documentation for j2cl is making things quite painful. I seen you separated a lot old gwt classes in independent projects. But I am not sure how to use them with bazel. To be honest I am not very familiar with bazel. For example, if I wish to use gwt-core, how does it works with bazel? There is a pom.xml, but no BUILD file...
    Dmitrii Tikhomirov
    @treblereel
    @PaulSitarz do you really need to know bazel ?
    @PaulSitarz i think, you want to make your project j2cl-compatible
    what you can do at this moment: replace gwt-user lib from deps, replace imports from your code with org.gwtproject (gwt-dom, gwt-core and etc), replace gwt-maven-plugin with j2cl-maven-plugin add run your tests with j2cl:test to be sure all good
    Colin Alworth
    @niloc132
    @PaulSitarz bazel can bring in maven dependencies - but unless you are actively interested in using bazel, that probably isn't the way to go. i am using bazel at this time only because i have to, not because i expect that even 10% of existing GWT-compatible projects out there will move to it (i'd be surprised if it was even 1% in the next 5 years for existing projects - new projects will probably be more)
    Paul Sitarz
    @PaulSitarz
    @niloc132 Thank you! No, I do not need to learn bazel, I have more interesting things to do. Though I am new to j2cl, and I do not know yet what should I do, and what is not necessary. By the way, about my question on how to access private fields, it works perfectly with jsinterop/native.js.
    Colin Alworth
    @niloc132
    @PaulSitarz to port to j2cl, i encourage you to first port to jsinterop, and any required gwt-* modules you need to do that - after that cleanly builds (including any bugs that may need to be reported to the org.gwtproject repos..), moving to j2cl itself should be fairly straightforward
    native.js only works in j2cl, gwt2 ignores it fwiw - and yes, it should work, since j2cl/jsinterop-base internally uses it, but is pretty clearly a hack - and if not tagged as @JsMethod or @JsProperty, may break as j2cl calling conventions change
    if you can depend on org.gwtproject deps and replace jsni, you can try one of the candidate j2cl-maven-plugins that we're working on in an app which depends on your lib, and see how it goes
    Paul Sitarz
    @PaulSitarz
    I already used jsinterop a lot, and I have minimal dependencies with gwt. XGL has its own widget hierarchy, dom elements wrappers, and event management. I think if I can get a good grasp on how efficiently build things with j2cl the port should be easy.
    Colin Alworth
    @niloc132
    if that's the case, you might not need a port at all - our intention is that, all else equal, the same libs should work in both j2cl and gwt2
    if you are doing tricks with native.js, this may not be true for you
    if you think you're already there, try adding the repo.vertispan.com/j2cl maven repository, add a .native.js to an entrypoint, and see if you can run j2cl-maven-plugin on it
    or skip the entrypoint, and just run a GWTTestCase (there are a few dependencies to add to support this in j2cl)
    Paul Sitarz
    @PaulSitarz
    The native.js stuff is for my serialization library, so it is a separate issue. I use this library to communicate with a server via websockets, and also between the main page and webworkers. Last year I patched gwt-2.8.2 to bring webworkers to the gwt world, do you remember it?
    Colin Alworth
    @niloc132
    i'm afraid i dont remember specifically, it gets discussed every 6-12 mos i figure
    you say you patched gwt 2.8.2? rather than add a linker? i can't think of another reason that gwt would need a change to support service/shared/web workers
    Paul Sitarz
    @PaulSitarz
    Because I wanted to be able to run both the main apps and the webworkers in super dev mode together. https://www.xalys.com/2018/06/13/web-workers-in-super-dev-mode
    Colin Alworth
    @niloc132
    ah gotcha ok
    i dont remember how that shook out, the worker i'm usually running i just build as PRETTY for prod, since i'm integrating with a react js project as the frontend
    Miroslav Pokorny
    @mP1
    @niloc132 Can i suggest that all your tips typed above about migrating be placed in a github project called j2cl-faqs or something...
    Colin Alworth
    @niloc132
    @mP1 agreed. we wrote it up a while ago, but decided not to publish it since it was too early and not enough things were ready to use yet. now, 18 mos later, we're near the point of wanting more than experimenters to try it out
    it would achieve the opposite of our goals if teams jumped ahead of time and ended up with unstable projects - "rewrite your codebase every 6-18mos and try new things on the way!" is the opposite of what we believe
    Miroslav Pokorny
    @mP1
    @niloc132 Cant use vertispan/connected while its mostly elemental2 its uses gwt events in a few places...had a look at https://github.com/DominoKit/dominodo/tree/master/dominodo it appears to use elemental2, the client side half should be a good test candidate.
    Colin Alworth
    @niloc132
    @mP1 i'm not sure i'm following - gwt-events doesnt solve the same problem as elemental2 though, gwt-events provides a strongly typed object model for events, while elemental2 provides a "wrapper" for the browser.
            boxesAndLines.addSelectionHandler(event -> {
                Person person = event.getSelectedItem();
                if (person.getBirthday() == null) {
                    person.setBirthday(new Date());
                }
                String newName = DomGlobal.prompt("change name?", person.getName());
                person.setName(newName);
                boxesAndLines.updateBox(person);
            });
    with browser-style events and the elemental2 event, you'd have to do something like boxesAndLines.addEventListener("selection", event ->...,and then cast the Event to CustomEvent, read CustomEvent.details, and cast that to the actual Person that i read on the first line there
    this project is arguably too small to really take advantage of gwt-events, but for very large projects it can be extremely useful to decouple in this way
    this also gives your plugin a very simple taste of transpiling extremely simple third party dependencies - gwt-events is as simple as they come, it is already gwt compatible, and has zero dependencies (beyond the jre, of course - not even jsinterop base or annotations)
    Miroslav Pokorny
    @mP1
    @niloc132 not discussing the purpose, just saying that "vertispan/connected" is a bad choice for testing non gwt lib j2cl compiling support
    Colin Alworth
    @niloc132
    it isnt a sample of testing non-gwt lib stuff at all
    it is an extremely small project, but bigger than hello-world, that's all
    if you want "test a non-gwt lib", hang on, i've got one i've been meaning to update...