Consider rebasing gwt-interop-utils on top of the just-released by Google jsinterop-base

Question

Consider rebasing gwt-interop-utils on top of the just-released by Google jsinterop-base

Closed this issue 6 years ago · 4 comments

Exciting news from today!

A beta of Elemental2
A beta of something called jsinterop-base, which is a few utility classes for dealing with JS notions that do not correspond directly to notions/language constructs in Java

jsinterop-base has a lot of overlap with gwt-interop-utils. Given that jsinterop-base will likely be used by Elemental2 and whatnot, it is highly desirable to unite gwt-interop-utils with jsinterop-base.

Perhaps two options:

Option 1: Retire gwt-interop-utils and switch all the code to the (more spartan) jsinterop-base
Option 2: Rebase gwt-interop-utils on top of jsinterop-base

If we go for Option 2, we might risk it that as jsinterop-base grows, we might have to deprecate more and more of gwt-interop-utils. On the other hand, jsinterop-base does not have any server-side story, so some parts of gwt-interop-utils should probably stay.

Some "thinking loud" how rebasing might work:

client package:

JsArray -> replaced completely by JsArrayLike + JsArrayLikeOfAny
JsStringMap -> replaced completely by JsPropertyMap + JsPropertyMapOfAny
JsPlainObj -> replaced completely by JsPropertyMapOfAny

shared package:

Array -> either replaced completely by JsArrayLike + JsArrayLikeOfAny, or rebased on top of these. Perhaps, inheriting from JsArrayLike, and having an additional static Array<T> as(JsArrayLike<T> array) method performing a cast from JsArrayLike<T> to Array<T>. Array<T> is anyway simply exposing more recent methods of JavaScript arrays, introduced with ES6/ES7, isn't it?
StringMap -> either replaced completely by JsPropertyMap + JsPropertyMapOfAny, or rebased on top of these. See the reasoning form above.
ForEachFn -> ? replaced completely by JsForEachCallbackFn
Following might have to stay: ForEachFullFn, MapFn, MapFullFn, ReduceFn, ReduceDoubleFn, ReduceFullFn, SortFn

The rest, including the conversions from Java Iterable and ArrayList to JS array and the other way around should stay.

pstockley commented 6 years ago

Done

Answer 1 · 2017-04-06T16:50:00.000Z

I took a quick look and it looks like we could migrate to just use elemental2.core.Array instead of Array (this provides all the same ES5 api as my version). I want to let google stabilize the elemental API first. Then look at slimming gwt-interop-utils down to just the additions they don't provide. I suspect we can make gwt-react only depend on elemental and also remove any dependency on com.google.gwt.dom.* at the same time.

Answer 2 · 2017-04-06T17:00:49.000Z

Looks like in order to keep the server capabilities I will need to keep my Array interface. Didn't realize elemental2.core.Array was a class. If I can make gwt-react only depend on elemental then I would be happy to keep jsInterop utils for people who want to share the same code on client and server. I am sure some interop between gwt.interop.utils.shared.collections.Array and elemental2.core.Array could be provided to allow mixing the two.

Answer 3 · 2017-04-07T06:10:07.000Z

Yes. Also, I'm not sure you would like to introduce dependency on Elemental2. Depending on jsinterop-base - yes, but on a DOM library... - probably not.