#168 fix: resolve WebSocket initialization race condition

[subhu339]

#168

The issue: Sometimes the app tries to start before Neutralino has finished setting up the NL_PORT in the window. This happens a lot with Vite or when the app loads really fast, leading to "undefined" websocket errors.
The fix: I made the init function async so it can wait for those variables to exist. I added a small waitForGlobals helper that polls for the port and token with a 5-second timeout so it doesn't hang forever if something goes wrong.

Testing:
Tested on Windows.
Confirmed it waits correctly and connects on the first try now.
Verified that init is now an async function in the browser console.

[Jatin24062005]

@subhu339 I don’t think this solution is incorrect, but I’m concerned it treats a synchronization problem with polling and timeouts.

The root issue seems to be that the Neutralino client has no explicit signal that the native layer has finished injecting runtime configuration.

From a library design perspective, waiting in a loop for globals introduces nondeterminism and hides the real lifecycle contract.

Would it be possible to expose an explicit “native-ready” signal (event / promise / guaranteed injection order) so the client can synchronize without polling?

[subhu339]

Thanks for the feedback, You're right—an explicit signal from the native layer would be the 'perfect' architectural fix. However, that would likely require changes to the C++ core across all platforms to ensure the signal is fired at the exact right moment.

This PR is a pragmatic fix for the JavaScript client to handle the race condition as it exists now. It solves the immediate problem for people using Vite/HMR without waiting for a core engine rewrite. If the maintainers decide to go the 'native signal' route later, this polling logic can easily be replaced.

[Jatin24062005]

I understand the need to unblock users quickly, but I don’t think time-based polling should live permanently in the core JS client. This feels more like a workaround for a specific setup (Vite/HMR) rather than a deterministic lifecycle guarantee.
If this is meant as a temporary fix, I’d suggest documenting it as a user-side workaround in the issue instead of merging it. For a long-term solution, an explicit readiness/signal-based approach would be more appropriate, even if it requires native-layer changes.

Thanks for the feedback, You're right—an explicit signal from the native layer would be the 'perfect' architectural fix. However, that would likely require changes to the C++ core across all platforms to ensure the signal is fired at the exact right moment.

This PR is a pragmatic fix for the JavaScript client to handle the race condition as it exists now. It solves the immediate problem for people using Vite/HMR without waiting for a core engine rewrite. If the maintainers decide to go the 'native signal' route later, this polling logic can easily be replaced.

[subhu339]

I understand your point about a native signal, but this PR is for the JavaScript client repository. Requiring a cross-platform C++ core change to fix a client-side race condition creates a massive barrier for a fix the community needs now.

Polling is a standard way to handle bridge initialization in many similar frameworks. This fix makes the library just work for modern dev tools like Vite without waiting for a major engine rewrite. If a native signal is added later, we can easily update this function to use it.