I think it's safe to assume that events could be recorded at a much higher rate than flags are evaluated, so they should definitely be batched and flushed in the background. The current implementation is probably good enough to validate the idea in a PoC but I would exclude this method from this SDK's public/versioned API until we can implement event batching.

This method being async is also not ergonomic to use on event handlers for DOM events like clicking, hovering or navigating.

I can't think of a case where we'd track events often, and even if they were it'd happen way less than flag evaluations since they'd occur potentially every render. The only usecase I can imagine is conversions e.g. checkout.

Another use case for batching (or decoupling tracking from pushing) is for mobile/low-powered devices, where you might want to either not send events or reduce the rate at which they're sent when running on battery or on metered connections. This is a tradeoff between metrics accuracy and device impact that customers need to make, so I'd like to have some API that lets them make this decision.

I suppose nothing prevents customers from implementing the batching themselves if they really want, so maybe we could rename this to pushEvent and add trackEvent/flushEvents/whatever later. At least that way it's clearer what this method does, and leaves the door open for a batched API in the future.