$entry() wrapper and JsInterop

[Ignacio Baca Moreno-Torres]

What is going to happen with $entry() utility? Some guidance in the JsInterop gdoc will be a good idea so libs-creator can apply a uniform strategy.

Elemento, for example, is waiting to see what to do (https://github.com/hal/elemento/issues/18), but there are various libraries already using JsInterop that are just ignoring $entry() and may produce unexpected behavior for its users.

There are 2 "radical" possibilities

1. Deprecate user.Scheduler.

2. Strongly recommend wrapping everything with $entry (don't think is possible to enforce this).

There is a dirty option of not wrapping JsInterop callbacks with $entry but maintains always a timer that tries to execute un-fired events. The problem is that finally scheduled command will behave as deferred commands. Another dirty option is to maintain a flag so the user can only schedule finally commands if the stack was nested inside a $entry call. Those don't seem good options.

Just curious, how is this solved in j2cl? j2cl still uses a custom scheduler or it only uses native js schedulers and timers? 

[Jens]

Take a look at https://gwt-review.googlesource.com/#/c/18540/ for a possible solution.

-- J.

[Thomas Broyer]

j2cl is "only" a transpiler, it doesn't provide event handling or scheduling or whatever. I highly doubt Google is using com.google.gwt.core.client.Scheduler along with j2cl.

There's a change under (active) review that would route window.onerror to the GWT.UncaughtExceptionHandler, so that at least $entry() would no longer be needed for that use-case: https://gwt-review.googlesource.com/c/18540/

For scheduleEntry/scheduleFinally, this will have to be discussed at the same time as widgets (as this is actually quite related).

$entry() is a "framework-y" part of GWT that we might want (personal opinion) to eventually remove, but there needs to be some replacement (not necessarily in terms of API, possibly guidelines on what to use instead, how to possibly refactor/rearchitect some code). scheduleFinally could possibly be replaced with Promise.resolve().then(…). scheduleEntry is trickier and would likely require bigger refactorings in code that uses it today.

[Ignacio Baca Moreno-Torres]

Some related links:

https://stackoverflow.com/questions/22519254/how-to-use-gwt-entry-function-in-jsni

https://groups.google.com/forum/#!topic/google-web-toolkit/Lf6aQG9al-Q

https://gwt-review.googlesource.com/#/q/file:user/src/com/google/gwt/core/client/internal/Entry.java

Nice, 18540 sounds good! no downsides and will make JsInterop more predictable, hope 2.8.2 gets soon. Ideally, with some basic guidelines about Scheduler in apps using JsInterop, maybe with this com.google.gwt.core.client.internal.Entry helper class. But, waiting to discuss widgets to get some conclusion to how to use JsInterop in an app with Widgets (legacy GWT) will be a bit late, isn't it? We are already using JsInterop + Widgets bc creating JS wrappers with JsInterop is much easier (https://github.com/search?utf8=%E2%9C%93&q=%5Bjsinterop%5D&type=), but I suppose you already now that, hehe just, I think that notes about guidelines to use JsInterop+Widget before taking any decision about the future of widgets will be... nice.