Nice :) I'd be interested in decisions it makes while talking to the backend. Eg it seems fairly smart about batching, events together, which is one of my frequent issues with tracking tools (b/c when done poorly, it wastes users' data plan and battery) I guess, for me, efficient use of resources is an important feature, so if you're intending to make more of these, that'd be a cool topic :)
SS where I modified the codepen to emit the event 5 times, but in different ticks of the event loop, and it batched them all into a single request:
Thanks Josh! The events are stored in a small, session-persistent buffer and sent in short intervals and/or when the buffer is full - both, time and size, are configurable. Of course, there's always a chance that if a user clicks an external link some events might never be sent, but that could also be the case if you'd set the buffer size to 0 to force an immediate request.
Sending events in packages, besides the benefits you mentioned, helps to avoid reaching the limit of parallel connections both, in a browser and in the backend. Considering how many different tracking services are installed on every website, managing resources is critical.
One of the hardest decisions building the lib was to drop support for promises, simply because the polyfill would significantly increase the size.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice :) I'd be interested in decisions it makes while talking to the backend. Eg it seems fairly smart about batching, events together, which is one of my frequent issues with tracking tools (b/c when done poorly, it wastes users' data plan and battery) I guess, for me, efficient use of resources is an important feature, so if you're intending to make more of these, that'd be a cool topic :)
SS where I modified the codepen to emit the event 5 times, but in different ticks of the event loop, and it batched them all into a single request:
Thanks Josh! The events are stored in a small, session-persistent buffer and sent in short intervals and/or when the buffer is full - both, time and size, are configurable. Of course, there's always a chance that if a user clicks an external link some events might never be sent, but that could also be the case if you'd set the buffer size to 0 to force an immediate request.
Sending events in packages, besides the benefits you mentioned, helps to avoid reaching the limit of parallel connections both, in a browser and in the backend. Considering how many different tracking services are installed on every website, managing resources is critical.
One of the hardest decisions building the lib was to drop support for promises, simply because the polyfill would significantly increase the size.