Adding onCompletion callback for when path configuration is loaded

[donnfelker]

This PR ads a completion callback mechanism to the path configuration loading. A default implementation is provided so that the existing API surface does not break existing consumers.

This callback will get invoked anytime the path configuration is loaded. There are three places a path configuration could be loaded from:

1. Local assets
2. Cache
3. Remote Url

The callback is invoked for each configuration is loaded. If all three are successful the onCompletion handler will be invoked 3 times.

A test is included to validate the behavior.

Use Case

With Jumpstart Android we have a use case where we update the settings block to include tabs. Some users need to update the tabs based upon logged in state of a user (the remote path configuration settings change if the user is logged in). After a successful login, we re-load the path configuration. However we need to know when the path configuration is done loading so that we can perform some actions on the client to check for new settings values.

[jayohms]

I'm a fan of this @donnfelker, thanks! We'll want a similar feature on iOS as well, so we can maintain parity.

Since it'll be a new public API, it might be valuable to pass along the source of the path configuration in the completion handler to handle different application concerns. Something like Bundled, Cached, and Remote source indicators. What do you think?

[joemasilotti]

iOS handles this via the PathConfigurationDelegate.

[jayohms]

Ah, I see that now @joemasilotti, thanks. So, what does that look like when using the Hotwire.loadPathConfiguration() API entrypoint?

[joemasilotti]

import HotwireNative
import UIKit

class TabBarController: UITabBarController {
    private let pathConfiguration = PathConfiguration(sources: [
        // ...
    ])

    override func viewDidLoad() {
        super.viewDidLoad()
        pathConfiguration.delegate = self
    }
}

extension TabBarController: PathConfigurationDelegate {
    func pathConfigurationDidUpdate() {
        // Do something with the update.
    }
}

[donnfelker]

@jayohms we could add those types, and I considered it because I would find it helpful, but I did not do that here as to not conflate the change. But I can add if if you'd like. Please let me know.

[jayohms]

@donnfelker thinking about this more, I think I'd prefer to separate Hotwire.loadPathConfiguration() from the ability to observe the path config loading state. A separate top-level Flow (or variant) where the state can be observed from an Activity, Fragment, etc with a lifecycle scope makes more sense long-term.

It's likely that Hotwire.loadPathConfiguration() will be called from the Application class, while observing load completion needs to be done somewhere else like the Activity. And if we're doing this, I think it makes sense to maintain a state that includes what source(s) have loaded.

[jayohms]

I haven't forgotten about this. I was hoping to get it in before 1.2.0, but didn't have time. I'm planning to work on this in the next couple weeks and propose an alternative approach.

[donnfelker]

No worries @jayohms I havent had time to look at it either. I agree with your approach. Normally it will be called from the application class, but I had to do some magic with injecting a base url so I could get this to work with MockWebServer and a dynamic base url for testing so I had to do it in the Main Activity. Maybe theres a better way to do it, but thats what I had to do to get it to work, I just ran out of time hacking on it.

However, back to the other topic, a flow would be great with a stateIn or something like that would likely work. Just spitballing right now.