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? -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9690b5c1-5d70-41a6-939d-fb614344c960%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
