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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. 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.
