You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally, we do not depend on deprecated stuff. However, we need to be careful if we remove event (which by the way is exposed as an uninvocable function*) as we need some other means for retrieving the event context.
I see two approaches:
Require all user-defined event handlers to accept the current event as a parameter. This would enforce a strong restriction on the type of things one can put inside l:.
Have the Links Javascript runtime record and store the current event (similarly to how it is done now). Change event : Event to getCurrentEvent : () ~> Option(Event), which returns None if it is invoked outside of an event handling context or Some(ev) if inside an event handling context, where ev would then be bound to the current event. If done naively (as it is currently the case) then different event handlers can read different events depending on when they invoked getCurrentEvent, we can probably rectify this by making the JavaScript process scheduler take care of the event bookkeeping.
* In the REPL
links> event;
fun : Event
links> event();
<stdin>:1: Type error: The function
`event'
has type
`Event'
while the arguments passed to it have types
and the currently allowed effects are
`wild:()'
In expression: event().
The text was updated successfully, but these errors were encountered:
dhil
changed the title
Event handlers depend on deprecated feature
Event handlers depend on a deprecated feature
Feb 10, 2022
The implementation of event handlers in Links depends on the deprecated property
window.event
(c.f. https://developer.mozilla.org/en-US/docs/Web/API/Window/event). Links exposes this property via a built-in global variable calledevent
.Ideally, we do not depend on deprecated stuff. However, we need to be careful if we remove
event
(which by the way is exposed as an uninvocable function*) as we need some other means for retrieving the event context.I see two approaches:
l:
.event : Event
togetCurrentEvent : () ~> Option(Event)
, which returnsNone
if it is invoked outside of an event handling context orSome(ev)
if inside an event handling context, whereev
would then be bound to the current event. If done naively (as it is currently the case) then different event handlers can read different events depending on when they invokedgetCurrentEvent
, we can probably rectify this by making the JavaScript process scheduler take care of the event bookkeeping.* In the REPL
The text was updated successfully, but these errors were encountered: