interaction-tracking package #13234

bvaughn · 2018-07-18T22:30:04Z

Backstory

We've recently introduced an experimental profiler API along with a prototype DevTools integration. After discussing this API with a few teams at Facebook, one common piece of feedback is that the timing information is useful, but would be more useful if it could be associated with "events" (e.g. button click, XHR response).

Event tracking would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "What's the wall time for this interaction?". It would also enable the DevTools Profiler plug-in to show a more meaningful, event-based timeline view.

This PR introduces a new API for tracking interactions. PR #13253 integrates this package with React and the experimental profiler API.

High level goals

User-facing API should be simple. (It should be easy to record an event.)
It should be possible to instrument (e.g. listen to all DOM Events on a page and track them) in a lightweight way.
Event information should be accessible to the DevTools profiler plug-in.
Tagged events should have minimal impact on the performance of profiling bundles and no impact on the production bundle.
External code should be able to subscribe to interactions in order to be notified when one "begins" (is first tracked) and "ends" (has no more pending async work).
It should be possible to attribute time spent working on interactions to specific workers (referred to as "threads" in the code). More on this below...

Tracking interactions

The tracking API is conceptually similar to zones. track is called to register a new event, and work is done in a callback. React automatically associates the work done in the callback with the current event(s) and passes them to the profiler's onRender callback when the work is eventually committed.

For example, you might track an event for (re)rendering your application:

import { render } from 'react-dom';
import { track } from "interaction-tracking";

track('rendering application', () => {
  // Both this render,
  // And any cascading update caused by cDM/cDU lifecycles,
  // Will be associated with the "rendering application" event.
  render(<MyApp />, container);
});

Or you might track a user interaction that triggers a state-update:

import React, { Component } from "react";
import { track } from "interaction-tracking";

class LoginForm extends Component {
  render() {
    // ...
  }

  handleLoginButtonClick = event => {
    track("login button clicked", () => {
      // Both the update caused by this initial setState,
      // And any cascading update caused by the login callback,
      // Will be associated with the "login button clicked" event.
      this.setState(
        {
          isLoggingIn: true
        },
        () => this.props.logInUser(this.state.user, this.state.password)
      );
    });
  };
}

If your application tree has a profiler component (React.unstable_Profiler) then the tracked information will be passed to its onRender callback as an additional array param. That information might look something like this:

[{id: 123, name: 'login button clicked', timestamp: 1234}]

Basic API

`clear(callback: Function) => any`

Resets the interaction stack temporarily, allowing new work to be tracked without appending to previous interactions. The callback function will be executed and its return value will be returned to the caller.

`getCurrent() => Set<Interaction>`

Returns the current set of interactions.

`track(name: string, callback: Function, threadID: number = 0) => any`

Tracks a new interaction (by appending to the existing set of interactions). The callback function will be executed and its return value will be returned to the caller. Any code run within that callback will be within that interaction "zone". Calls to wrap() will schedule async work within the same zone.

A threadID can be passed to specify who is performing the current work. This value defaults to 0 which can be thought of as the global "thread".

`wrap(callback: Function, threadID: number = 0) => Function`

Wrap a function for later execution within the current interaction "zone". When this function is later run, interactions that were active when it was "wrapped" will be reactivated.

The wrapped function returned also defines a cancel() property which can be used to notify any tracked interactions that the async work has been cancelled.

A threadID can be passed to specify who is performing the current work. This value defaults to 0 which can be thought of as the global "thread".

Advanced API

By default, the interaction-tracking package only manages interaction "zones". In order to build more complex logic on top of this package, it also supports an subscrible API. Subscribers can be added or removed using subscribe() and unsubscribe() methods. A subscriber should implement the following API:

`onInteractionTracked(interaction: Interaction) => void`

A new interaction has been created via the track() method.

`onInteractionScheduledWorkCompleted(interaction: Interaction) => void`

All scheduled async work for an interaction has finished.

`onWorkScheduled(interactions: Set<Interaction>, threadID: number) => void`

New async work has been scheduled for a set of interactions. When this work is later run, onWorkStarted/onWorkStopped will be called.

A batch of async/yieldy work may be scheduled multiple times before completing. In that case, onWorkScheduled may be called more than once before onWorkStopped.

Work is scheduled by a "thread" which is identified by a unique ID.

`onWorkStarted(interactions: Set<Interaction>, threadID: number) => void`

A batch of work has started for a set of interactions. When this work is complete, onWorkStopped will be called. Work is not always completed synchronously; yielding may occur in between.

A batch of async/yieldy work may also be re-started before completing. In that case, onWorkStarted may be called more than once before onWorkStopped.

Work is done by a "thread" which is identified by a unique ID.

`onWorkCancelled(interactions: Set<Interaction>, threadID: number) => void`

A batch of scheduled work has been cancelled.

Work is done by a "thread" which is identified by a unique ID.

`onWorkStopped(interactions: Set<Interaction>, threadID: number) => void`

A batch of work has completed for a set of interactions.

Work is done by a "thread" which is identified by a unique ID.

pull-bot · 2018-07-18T22:40:46Z

Details of bundled changes.

Comparing: e020408...6e31ec3

interaction-tracking

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
interaction-tracking.development.js	n/a	n/a	0 B	8.2 KB	0 B	2.33 KB	UMD_DEV
interaction-tracking.production.min.js	n/a	n/a	0 B	731 B	0 B	438 B	UMD_PROD
interaction-tracking.development.js	n/a	n/a	0 B	8.01 KB	0 B	2.26 KB	NODE_DEV
interaction-tracking.production.min.js	n/a	n/a	0 B	589 B	0 B	355 B	NODE_PROD

Generated by 🚫 dangerJS

bvaughn · 2018-07-26T17:18:00Z

packages/interaction-tracking/src/InteractionZone.js

+  };
+}
+
+export function startContinuation(context: ZoneContext): void {


The start/stop continuation methods aren't really intended for user-facing use. They enable React to restore previous context when processing work asynchronously.

While testing the new DevTools profiler, I noticed that sometimes– in larger, more complicated applications– the actualDuration value was incorrect (either too large, or sometimes negative). I was not able to reproduce this in a smaller application or test (which sucks) but I assume it has something to do with the way I was tracking render times across priorities/roots. So this PR replaces the previous approach with a simpler one.

bvaughn · 2018-08-04T21:14:37Z

Feedback from the Web Speed team has been incorporated. A new module, InteractionEmitter, has been added that will enable external code to monitor when new interactions are scheduled and when they start/stop. This should enable them to do more in-depth tracking without bloating the open source package.

The only open question (that I can think of at the moment) is how we can change continuations to accommodate the fact that multiple interactions might get batched into a single React commit. The current API assumes that you'll only restore a single interaction context (a "continuation").

… PROD

bvaughn · 2018-08-14T21:44:05Z

I think I've responded to all of the feedback about this PR 👍

gaearon · 2018-08-14T22:48:25Z

packages/interaction-tracking/src/InteractionTracking.js

+      }
+    }
+
+    if (caughtError !== null) {


Nit: this would swallow throw null.

In React, we solve this by having a wrapper function that toggles a boolean if an error was set.

True. That occurred to me but seemed unlikely. I'll replace it with a bool though!

bvaughn · 2018-08-15T16:45:38Z

PR has been updated with the following changes:

More tests added specifically around error handling in subscriber method(s).
Array of subscribers has been replaced with a single subscriber in order to simplify said error handling logic. (Web Speed team is okay with this change.)

Should be ready for final review/merge now, since nothing actually references this new package until PR #13253 (and the feature flags are all off by default).

cc @acdlite @sebmarkbage 😄

sebmarkbage

Looks good. Mostly a bunch of nits.

sebmarkbage · 2018-08-17T05:35:24Z

packages/interaction-tracking/src/InteractionTracking.js

+    return callback();
+  }
+
+  const interaction: Interaction = {


This will provide a hint to the VM that we only want 3 inline fields but they you add an expando later.

We should always provide the four fields in initialization. If you want to exclude on when the feature flag is not used you can initialize the object in a conditional.

In the three field case you can cast it to any and then back to Interaction.

Ah, good call. Thanks!

sebmarkbage · 2018-08-17T05:36:23Z

packages/interaction-tracking/src/InteractionTracking.js

+import now from './InteractionTrackingNow';
+
+export type Interaction = {|
+  __count?: number,


This should be required.

I realize it won’t be there in one of the feature flags but we can assume it always is. That way you don’t need all the any casts whenever you access this which might cover up other issues.

sebmarkbage · 2018-08-17T05:41:09Z

packages/interaction-tracking/src/InteractionTracking.js

+// Interactions "stack"–
+// Meaning that newly tracked interactions are appended to the previously active set.
+// When an interaction goes out of scope, the previous set (if any) is restored.
+let interactionsRef: InteractionsRef | null = null;


You can cast the null to any so that this can be non-nullable. That way the fact that this is dependent on feature flags is hidden in one place instead of spread throughout the code.

Every use of any could be a typo/miscast.

Interesting.

Using "any" to mask a null initialization value seems equally potentially dangerous but... I don't mind removing all of the Flow casts 😅

Both cases has the danger of us using a field while not in the feature flag branch.

In the previous approach, every time you use it risk typing (interactionsRef: any) instead of ((interactionsRef: any): InteractionsRef) which would cover up additional errors.

You also risk typing ((subscriberRef: any): InteractionsRef) which is just the wrong type.

The number of times you have to use any increases the risk of any of these types of additional mistakes.

When it is in a single location you only risk making this mistake once, but that's easy to review, and since you're using null as the initial value the risk of typing subscriberRef instead of null seems pretty small.

sebmarkbage · 2018-08-17T05:42:40Z

packages/interaction-tracking/src/InteractionTracking.js

+
+// Listener(s) to notify when interactions begin and end.
+// Note that subscribers are only supported when enableInteractionTrackingObserver is enabled.
+let subscriberRef: SubscriberRef | null = null;


sebmarkbage · 2018-08-17T05:59:06Z

packages/interaction-tracking/src/InteractionTracking.js

+      returnValue = callback();
+    } catch (error) {
+      didCatch = true;
+      caughtError = caughtError || error;


If you throw null in the first one, and this also throws, it’ll override with the second error. Not sure if that’s desireable. We can make this if (!didCatch) { didCatch = true; caughtError = error; }. That way we don’t have to rely on the sketchy falsey check. It will always rethrow the first throw value just like try finally.

sebmarkbage · 2018-08-17T06:00:30Z

packages/interaction-tracking/src/InteractionTracking.js

+    interaction.__count = 1;
+
+    let caughtError;
+    let didCatch = false;


If you just use nested try/finally where each next level is in the finally, I don’t think you need to use these temporary variables or any catch blocks. That’d probably be better perf wise too.

Hm...I could do this, but it would end up throwing the last error, rather than the first. Right?

Hm. You're right. It might be worth it though. Just for smaller code and doesn't require the VM to set up registers and initialize these values. It becomes a noop. We don't expect the handlers to ever throw so optimizing for that seems valuable.

Okedoke. I'll change it.

sebmarkbage · 2018-08-17T06:01:25Z

packages/interaction-tracking/src/InteractionTracking.js

+
+      try {
+        let caughtError;
+        let didCatch = false;


Same thing here. You can just use nested try/finally.

sebmarkbage · 2018-08-17T06:16:26Z

packages/interaction-tracking/src/InteractionTracking.js

+  const interaction: Interaction = {
+    id: interactionIDCounter++,
+    name,
+    timestamp: now(),


Since there is nothing else in here that deals with timestamps, it seems better that this is passed in instead. That way the time mechanism doesn’t have to be built in. Eg we are considering a custom measurer at FB and RN might need something else.

In fact for certain tracking I believe that is required. Eg for a click you want the time at the time the user released. Not towards the end of the processing of the click event. The mouseup event could’ve spent time too. For requestAnimationFrame you want the time stamp passed into the callback (beginning of the frame), not the current time.

Additionally we don’t even know which scale is appropriate to use. Date.now and performance.now use different time scales and whatever they’re going to be compared to (eg) commit time needs to line up.

If we’re going to automatically track time here, then we should also pass time to the complete callbacks so that the external system gets consistent time. But I see no reason for that.

We can just have the user of the track api pass the current time in as an argument. That makes this package a bit lighter too.

Hmm...that would make the API feel clunkier to me ☹️but if you think it's important/necessary, I trust your judgement.

That makes this package a bit lighter too.

By such a tiny amount that it isn't really important 😁

acdlite · 2018-08-17T06:02:07Z

packages/interaction-tracking/src/InteractionTracking.js

+      ((subscriberRef: any): SubscriberRef).current === null ||
+        ((subscriberRef: any): SubscriberRef).current === subscriber,
+      'Only one interactions subscriber may be registered at a time.',
+    );


If only one can be scheduled at a time, maybe the API should be to mutate current directly.

Oh that is what React does. Why does this other API exist at all?

React mutates the interactionRef directly. Non-react things (e.g. Web Speed's code) will subscribe. I don't really want to expose the ref to things we don't directly control.

acdlite · 2018-08-17T06:03:20Z

packages/interaction-tracking/src/InteractionTracking.js

+import invariant from 'shared/invariant';
+import {
+  enableInteractionTracking,
+  enableInteractionTrackingObserver,


I don’t get why these feature flags exist

Or rather, I get why they exist for React but not why they are used by this package. Is it because we’re still inlining it instead of publishing as a separate module?

The enableInteractionTracking is used to make the production bundle no-op for interaction tracking (since nothing consumes that data).

The enableInteractionTrackingObserver flag is maybe not necessary, but I was using it when the subscription stuff was more obnoxious so that we could turn it off entirely if we decided to (e.g. for open source). I could remove this flag if we want.

acdlite · 2018-08-17T06:36:49Z

packages/interaction-tracking/src/InteractionTracking.js

+export function wrap(
+  callback: Function,
+  threadID: number = DEFAULT_THREAD_ID,
+): Function {


I don't think I understand why wrap is so complicated. I was expecting it to be essentially this:

function wrap(callback) { const continuedInteractions = interactions.current; retain(); return (...args) => { track(continuedInteractions, () => callback(...args)); release(); } }

where most of the code is reused from track

I suppose avoiding the extra function call is worthwhile, but I believe semantically they should be identical. See other comment: #13234 (comment)

I don't think wrap is that complicated. This approach avoids an extra function call and additional wrapper function.

Also the behavior of wrap/track are different. track is additive (stacking on top of what the current interactions are). wrap temporarily restores interactions at a previous point in time.

But... why?

Because that's kind of fundamental to how track and wrap work? I'm not sure I understand the question.

It doesn’t modify the current set of interactions because it will reset them back to the previous set after it exits.

No, I meant that it would modify the original set. So if I wrapped [foo,bar] I would expect my async work to be attributed to [foo,bar]– not [foo,bar,...whatever-else-was-also-active]

I think @acdlite's misunderstanding is a good opportunity to rename this function to something that makes it clearer. I could see how if I see track and wrap I would think that wrap is just a convenience for wrapTracked since it is highlighting the wrapping mechanism and nothing else.

In reality the purpose of wrap isn't to wrap a function. The primary purpose is to continue where you left off.

wrapContinuation? Too long. This is can be used a lot if you don't have auto-wrapping.

I suppose there's precedence for calling it wrap in Zones.

I like the brevity of "track" and "wrap" but I'm not bullish on them if others feel there are more meaningful names.

acdlite · 2018-08-17T06:42:04Z

packages/interaction-tracking/src/InteractionTracking.js

+
+  const wrapped = (...args) => {
+    const prevInteractions = ((interactionsRef: any): InteractionsRef).current;
+    ((interactionsRef: any): InteractionsRef).current = wrappedInteractions;


Almost always, this callback will be called at or near the top of the stack. But if it isn't, shouldn't this "stack/accumulate" interactions the same way track does? (If so, why not?) This is one of the reasons I assumed you would implement wrap on top of track.

My above comment mentions this. The behavior of wrap/track are intentionally different. track is additive (stacking on top of what the current interactions are). wrap temporarily restores interactions at a previous point in time.

acdlite · 2018-08-17T06:45:27Z

packages/interaction-tracking/src/InteractionTracking.js

+      }
+    } else {
+      try {
+        return callback(...args);


Nit: I think this is fine and Babel will compile it to callback.apply(undefined, arguments) but to be safe I usually prefer to manually use apply.

* Refactored some nullable Flow types * Moved __count into interactions inline object rather than adding field later * Changed didCatch condition to better handle thrown null value

bvaughn · 2018-08-17T15:30:23Z

I believe I've made all of the requested changes, except for the nested try/finally suggestion from Sebastian– since that would change throwing behavior.

sebmarkbage

I don't really understand how the feature flags work and how they're going to work to enable this. Will you need to alias the production build of this package too, or just ReactDOM to enable tracking?

But I'm satisfied.

sebmarkbage · 2018-08-17T15:46:35Z

packages/interaction-tracking/src/InteractionTracking.js

+        }
+      } finally {
+        try {
+          returnValue = callback();


You can actually just return here. The finally will still execute before returning.

Returning in finally masks thrown errors.

sebmarkbage · 2018-08-17T15:49:01Z

packages/interaction-tracking/package.json

+  "name": "interaction-tracking",
+  "description": "utility for tracking interaction events",
+  "version": "0.0.1",
+  "repository": "facebook/react",


Probably need to flush this package.json out a bit.

bvaughn · 2018-08-17T15:52:54Z

I don't really understand how the feature flags work and how they're going to work to enable this. Will you need to alias the production build of this package too, or just ReactDOM to enable tracking?

I could roll the interaction tracking feature flags into the enableProfiler feature flag in a follow up PR if folks find that more intuitive.

In general, the question of "how to use this in production" is the same for this package as for the profiling bundle of e.g. react-dom– and yeah, I assume you would just setup an alias in your bundler.

sebmarkbage · 2018-08-17T15:54:47Z

packages/interaction-tracking/src/InteractionTracking.js

+  return ++threadIDCounter;
+}
+
+export function subscribe(subscriber: Subscriber): void {


I kind of agree with @acdlite here.

We could have a separate module. interaction-tracker/observer that attaches itself to __subscriberRef directly but provides multi-listener support.

That could be the safe API. That way the minimal module remains even tinier by excluding the overhead of exposing these methods and this error message.

It's never really safe to listen to a single listener protocol directly regardless. The safe form is the multi-listener form.

Ok. I'll pull the subscribe/unsubscribe methods for now and re-add them in a follow up.

bvaughn · 2018-08-17T16:15:29Z

Thanks, everyone, for the thoughtful review! ❤️

I'm going to land this and do the following with a follow up PR:

Add a new target to the interact-tracking package (e.g. interaction-tracker/observer) that re-adds subscribe/unsubscribe functionality, along with multi-listener support.
Combine enableInteractionTracking and enableInteractionTrackingObserver feature flags since the distinction doesn't seem necessary anymore.

I'll then rebase and flatten PR #13253 before starting to respond to feedback.

facebook-github-bot added the CLA Signed label Jul 18, 2018

bvaughn mentioned this pull request Jul 22, 2018

[Experimental] API for reading context from within any render phase function #13139

Merged

bvaughn force-pushed the interaction-tracking branch from 0cf6399 to 9624848 Compare July 23, 2018 22:46

bvaughn mentioned this pull request Jul 23, 2018

Profiler integration with interaction-tracking package #13253

Merged

5 tasks

bvaughn added the Type: Discussion label Jul 23, 2018

facebook deleted a comment from facebook-github-bot Jul 26, 2018

bvaughn commented Jul 26, 2018

View reviewed changes

salazarm mentioned this pull request Aug 2, 2018

Interaction Tracking -- Observer context switching lifecycle. bvaughn/react#10

Merged

bvaughn mentioned this pull request Aug 3, 2018

Profiler RFC reactjs/rfcs#51

Merged

bvaughn mentioned this pull request Aug 3, 2018

Profiler plug-in for DevTools facebook/react-devtools#1069

Merged

5 tasks

Brian Vaughn added 2 commits August 3, 2018 14:06

Changed bubbling logic after chatting out of band with Andrew

6f996da

Added interaction-tracking package

8df2067

bvaughn force-pushed the interaction-tracking branch from 5a3df8d to 8df2067 Compare August 4, 2018 21:08

facebook deleted a comment from flarnie Aug 4, 2018

Incorporated feedback from Web Speed team

974d25e

Brian Vaughn added 9 commits August 5, 2018 12:29

Overhalled continuations to work with React's scheduler

14dffc7

Fixed production tests

ac6887d

Replaced __PROFILE__ with enableProfilerTimer feature flag

4418e72

Removed dep on shared/warning package

68bc9dd

Run interaction-tracking tests with profiling enabled in both DEV and…

f277c09

… PROD

Replaced console.error with warningWithouStack

112f2ec

Made InteractionTracking test internal since it depends on feature flags

5380b5f

Replaced __PROFILE__ with feature-flag conditionals in test

ae7e4fa

Merge branch 'profiler-timer-bugfix' into interaction-tracking

d98e713

bvaughn changed the title ~~Interaction tracking POC (for discussion purposes only)~~ New interaction-tracking package Aug 6, 2018

Brian Vaughn added 3 commits August 14, 2018 13:28

Improved subscriber error handling and added tests

b8287cf

Only support a single subscriber

012a9e6

let -> const

0509a9f

gaearon reviewed Aug 14, 2018

View reviewed changes

Handle 'throw null'

d5ebc31

bvaughn changed the title ~~New interaction-tracking package [WIP]~~ interaction-tracking package Aug 15, 2018

gaearon mentioned this pull request Aug 16, 2018

Add Support for User Timing API reduxjs/react-redux#972

Closed

sebmarkbage requested changes Aug 17, 2018

View reviewed changes

acdlite reviewed Aug 17, 2018

View reviewed changes

Brian Vaughn added 5 commits August 17, 2018 08:30

Misc Seb feedback:

4150607

* Refactored some nullable Flow types * Moved __count into interactions inline object rather than adding field later * Changed didCatch condition to better handle thrown null value

callback(...args) -> callback.apply(undefined, arguments)

21248f8

Added tests to ensure the first error was thrown

43a97f1

Pass timestamp into track() method; delete now()

d88cbb9

Operator assignment for brevity

69fd285

bvaughn requested a review from sebmarkbage August 17, 2018 15:29

Replaced multi try/catch with nested try/finally

cc45d8e

bvaughn force-pushed the interaction-tracking branch from 69ab7c7 to cc45d8e Compare August 17, 2018 15:45

sebmarkbage approved these changes Aug 17, 2018

View reviewed changes

sebmarkbage reviewed Aug 17, 2018

View reviewed changes

Brian Vaughn added 2 commits August 17, 2018 09:57

Added some details to package.json

d41bd61

Removed subscribe/unsubscribe methods from main export

6e31ec3

bvaughn merged commit 5e0f073 into facebook:master Aug 17, 2018

bvaughn deleted the interaction-tracking branch August 17, 2018 16:16

bvaughn mentioned this pull request Aug 17, 2018

Add interaction-tracking/subscriptions #13426

Merged

swyxio mentioned this pull request Aug 10, 2019

[old] removed profiler info swyxio/brain#24

Closed

interaction-tracking package #13234

interaction-tracking package #13234

Conversation

bvaughn commented Jul 18, 2018 • edited Loading

Backstory

High level goals

Tracking interactions

Basic API

clear(callback: Function) => any

getCurrent() => Set<Interaction>

track(name: string, callback: Function, threadID: number = 0) => any

wrap(callback: Function, threadID: number = 0) => Function

Advanced API

onInteractionTracked(interaction: Interaction) => void

onInteractionScheduledWorkCompleted(interaction: Interaction) => void

onWorkScheduled(interactions: Set<Interaction>, threadID: number) => void

onWorkStarted(interactions: Set<Interaction>, threadID: number) => void

onWorkCancelled(interactions: Set<Interaction>, threadID: number) => void

onWorkStopped(interactions: Set<Interaction>, threadID: number) => void

pull-bot commented Jul 18, 2018 • edited Loading

interaction-tracking

Choose a reason for hiding this comment

bvaughn commented Aug 4, 2018 • edited Loading

bvaughn commented Aug 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Aug 15, 2018

sebmarkbage left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acdlite Aug 17, 2018 • edited Loading

Choose a reason for hiding this comment

acdlite Aug 17, 2018 • edited Loading

Choose a reason for hiding this comment

bvaughn Aug 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Aug 17, 2018

sebmarkbage left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Aug 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Aug 17, 2018

bvaughn commented Jul 18, 2018 •

edited

Loading

`clear(callback: Function) => any`

`getCurrent() => Set<Interaction>`

`track(name: string, callback: Function, threadID: number = 0) => any`

`wrap(callback: Function, threadID: number = 0) => Function`

`onInteractionTracked(interaction: Interaction) => void`

`onInteractionScheduledWorkCompleted(interaction: Interaction) => void`

`onWorkScheduled(interactions: Set<Interaction>, threadID: number) => void`

`onWorkStarted(interactions: Set<Interaction>, threadID: number) => void`

`onWorkCancelled(interactions: Set<Interaction>, threadID: number) => void`

`onWorkStopped(interactions: Set<Interaction>, threadID: number) => void`

pull-bot commented Jul 18, 2018 •

edited

Loading

bvaughn commented Aug 4, 2018 •

edited

Loading

acdlite Aug 17, 2018 •

edited

Loading

acdlite Aug 17, 2018 •

edited

Loading

bvaughn Aug 17, 2018 •

edited

Loading

sebmarkbage left a comment •

edited

Loading