Events should be buffered until the async init is resolved and the SDK is able to capture events

[marandaneto]

Description

https://github.com/PostHog/posthog-js-lite/issues/182#issuecomment-1957534606 If RN is busy resolving lots of promises, some integrations such as useLifecycleTracker and others might bail out because posthog is yet not resolved. The goal is that those events are queued in a map with <timestamp, event> and later sent to the network in order (FIFO).

This also relates to https://github.com/PostHog/posthog-js-lite/issues/96 because it'd be easier if everything were async, or there was an option to be sync or async.

Another option is that those integrations are Posthog | Promise and resolve the promises instead of bailing out.

[benjackwhite]

I've thought about this a little before and as I see it there are two issues to solve:

1. Buffering capture type calls
2. Buffering get type calls

Capture calls are somewhat straightforward as we would "simply" need to intercept the calling function and add it to a queue to be reapplied once the async initialisation is finished.

Get calls are trickier as we would need handle methods like getting the distinct id. Either we would return undefined if the sdk isn't initialised or make all of these sort of methods async so that we can await the initialisation.

I don't think these are so hard that we shouldn't do it, we just need to consider those cases and user expectations

[marandaneto]

I think the user expectation would be that all events should be captured regardless the init is sync or async.

I'd also be sure that the timestamps are correct (the timestamp that was supposed to be captured) instead of the delayed timestamp, maybe a few milliseconds won't matter but worth considering, otherwise average session time might be affected due to delayed events.