Version 0.3 coming soon with setInterval and proper setTimeout, but also a significant change to behavior simplifying test cases.

[stroiman]

TLDR; You no longer need to synchronise tests to wait for immediate effects to occur, but you do need to explicitly tell it to fast-forward time for setInterval/setTimeout (with delay > 0) to callbacks to be called.

--

Event loop mistake

Originally Gost did not have a proper event loop. There was a setTimeout to get early HTMX tests to work, but the delay would always be considered 0. And the callbacks passed to setTimeout would execute in a separate goroutine.

Using a separate goroutine for the event loop was a design mistake.

• Browsers run the event loop in the main thread.
• This leads to race conditions, as both test code, and event loop callbacks can manipulate the DOM concurrently.

Also, early versions often panic'ed when shutting down V8. The very thing I was struggling with before the 0.1 release was thread synchronisation with mutexes, and it was mostly painful trial and error.

Bring control to the test thread

As a result of the two points, the event loop needs to run in the test thread. (that I could remove all mutexes was an added benefit)

But that also means that time doesn't pass in the test by itself, affecting e.g., throttled/debounced behaviour. You need to simulate the passing of time, by calling window.Clock().Advance(time.Duration) (using the standard library time package's type)

At the moment, JavaScript Date doesn't reflect time travel, i.e. new Date() or Date.now() reflect system time, not simulated time.

The syntax may change before 0.3 release; and perhaps the Date object may also reflect simulated time, with ability to control the initial value - let's see ...

Simpler test code

The initial HTMX test cases required some synchronisation, tests needed to wait for certain HTMX events, like htmx:load on first page load, to be sure all relevant HTMX event handlers had been configured.

With this change, everything that is scheduled to run at this moment in time will run before handing control back to test code. This means that you no longer need to synchronize.

Request for feedback

The default behaviour doesn't fast forward time, but executes what was scheduled at the current time after each JavaScript call has returned.

Use cases with animated transitions might require many explicit calls to clock.Advance. This could be remedied by a browser configuration option, to forward time automatically by some configurable amount after each call to JavaScript code.

But this is probably a little simple, because you might not want want the same amount of simulated time for keyboard event handlers, as other operations triggering page transitions.