-
-
Notifications
You must be signed in to change notification settings - Fork 57
Add JSTimer implementation with tests #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- I think it would make sense to use the standard
TimeIntervaltype here and convert it to the appropriate millisecond value to better match other Swift APIs - the API is pretty verbose. What do you think of this?
public final class JSTimer { public init(_ after: TimeInterval, _ callback: @escaping () -> ()) public static repeating(_ interval: TimeInterval, _ callback: @escaping () -> ()) }
I think it would make sense to use the standard TimeInterval type here and convert it to the appropriate millisecond value to better match other Swift APIs
It's reasonable. But unfortunately, TimeInterval is a type defined in Foundation and I don't want JavaScriptKit to depend on Foundation.
the API is pretty verbose. What do you think of this?
public final class JSTimer { public init(_ after: TimeInterval, _ callback: @escaping () -> ()) public static repeating(_ interval: TimeInterval, _ callback: @escaping () -> ()) }
I'm not sure this would work. repeating still has to delegate to some initializer, but there isn't one in this case that would call setInterval, if we assume that the only present init calls setTimeout. Then it would have to look something like:
public final class JSTimer { public init(millisecondsDelay: Double, isRepeating: Bool = false, callback: @escaping () -> ()) public static func repeating(millisecondsDelay: Double, callback: @escaping () -> ()) }
Maybe we could just add a default false value on isRepeating without adding static func repeating? WDYT?
Depends on #45. This is also a prerequisite for a future
JSPromisePR with tests.I intentionally didn't match the JS API in this PR, as a special care is needed to hold a reference to the timer closure and to call
.release()on it. Here, a user is supposed to hold a reference to aJSTimerinstance for it to stay valid. The API is also intentionally simple, the timer is started right away, and the only way to invalidate the timer is to bring its reference count to zero.If you see a better way to manage closures passed to
setTimeoutandsetInterval, I'd be happy to consider that.Also, Node.js and browser APIs are slightly different.
setTimeout/setIntervalreturn an object in Node.js, while browsers return a number. Fortunately,clearTimeoutandclearIntervaltake corresponding types as their arguments, and we can store either asJSValue, so we can treat both cases uniformly.