Ensure thread safety

[svara]

This PR ensures all classes and functions are thread-safe by adopting the @MainActor attribute.

With the adoption of async/await we've introduces potential race conditions and made some of the classes not thread safe.
A MainActor is a globally unique actor who performs his tasks on the main thread.

I think adopting MainActor makes sense because:

• it ensures thread safety throughout the library.
• BridgeDelegate is usually instantiated in a UIViewController, which conforms to MainActor itself, thus no additional code changes are needed.
• BridgeComponents are usually used to interact with UI, which must run on the main thread.

This PR also fixes an error when using the async version of evaluateJavaScript. More info here.

[joemasilotti]

I love that we can move @MainActor to the class level, great call! I added one question and one request, otherwise this looks good to me.

[svara]

When using async/await version of evaluateJavaScript, WKWebView expects JavaScript to return with a value (something other than Void). If there's no value returning from the JavaScript that you evaluate it will crash because it tries to unwrap a nil value to Any.

[svara]

I've tested these changes in the Calendar app, and so far haven't seen any regressions or issues.

[svara]

@joemasilotti Unfortunately I'm running into some issues. Will continue tomorrow.

[svara]

@joemasilotti Could you please give this branch a try in one of your projects? I'm running into an issue and can't seem to get it to work anymore. The components are successfully registered when the bridge sends 'ready', but after that, no more messages are received from the bridge. I've double-checked the code, but I'm unable to identify what might be causing this. I'm running out of ideas.

@zoejessica Could you please double check the code?

[joemasilotti]

I'm not seeing any components but I do see bridgeNotInitializedForWebView in the console.

I think making Bridge.initialize() async is breaking it. I need to return the web view right away to work with Turbo Navigator but it isn't initialized until the completion block calls.

Turbo.config.makeCustomWebView = { configuration in
    configuration.defaultWebpagePreferences?.preferredContentMode = .mobile

    let webView = WKWebView(frame: .zero, configuration: configuration)
    webView.makeInspectableInDebugBuilds()
    Bridge.initialize(webView) { }
    return webView
}

If this change is required we can refactor the makeCustomWebView block to be async as well.

[svara]

@joemasilotti I've seen bridgeNotInitializedForWebView when the web view is required right away. Subsequent calls do work though, however the components are still broken.

Man, it should be trivial to start a Task on the main actor in a synchronous way, when the task is started from the main thread. But nope. I'm still looking for alternatives.

[joemasilotti]

Man, it should be trivial to start a Task on the main actor in a synchronous way, when the task is started from the main thread.

Agreed, I just want a blocking call!

Does initializing the Bridge have to be asynchronous? What if there was a non-async option, too?

[svara]

Does initializing the Bridge have to be asynchronous? What if there was a non-async option, too?

Having @MainActor attribute enforces it. However, I can remove it from the class level, and only mark the async function with it.

[joemasilotti]

Excellent, everything is working for me, too!

[joemasilotti]

I had to manually merge this on the command line for some reason. Thanks @svara!