Bridge Components v0.10 is out

Introducing a new API for communicating with components. And one breaking change.

I just released a new version of my Bridge Component library, v0.10.0.

The library adds native integrations to your Hotwire Native apps. It unlocks production-ready bridge components without writing any custom Swift or Kotlin.

Add the package, wire up some HTML, and ship!

16 components are currently available and I’m always working on adding more. But this release doesn’t add a new component. It adds something I’m actually a bit more excited about.

The feature came from some work I’m currently doing for a client. They are using the Theme Component to switch the device’s dark/light mode to match the color scheme of the HTML and CSS.

But using this component with a tab bar meant that switching themes on one tab could cause the other tabs to become out of sync. And there was no way for developers to know when the theme was updated. Until now!

Observe component changes

This release includes a new helper to observe when a component makes changes.

React to the Theme Component changing the theme in Swift:

Bridgework.observe(.themeDidChange) { theme in
    print(theme)
}

And Kotlin:

Bridgework.observe(this, Events.themeDidChange) { theme ->
    Log.d(”THEME CHANGE”, theme.toString())
}

These examples show printing the name of the new theme to the consoles. My client is using the callback to reload all the tabs in the app to ensure everything is kept in sync.

And for developers using the Bridge Component PRO upgrade, you can now more easily send typed data to components. Like when a push notification token is registered on iOS:

Bridgework.post(.didReceiveNotificationToken, deviceToken)

To power this I introduced a new top-level namespace, Bridgework. Here’s why.

The Bridgework namespace

To better align the new helper methods, and not pollute the global namespace, all public APIs now live under Bridgework.

This means that you need to change your code that imports components from the library. On both iOS and Android, replace the following line:

Hotwire.registerBridgeComponents(BridgeComponents.all)

With:

Hotwire.registerBridgeComponents(Bridgework.coreComponents)

Or with the following for Bridge Component PRO users:

Hotwire.registerBridgeComponents(Bridgework.allComponents)

And you’re good to go!

This new event/observation system got me thinking that I could probably apply the same approach to JavaScript, too.

Future events and observers

JavaScript events could greatly improve the DX around some components, like the Search Component. This component adds a native search bar to the app and passes the typed query to JavaScript.

But it currently requires developers to subclass a specific Stimulus controller to handle queries. Migrating to events means that developers could instead observe an event and pass that directly to their own controller.

For example, by listening to the queryDidUpdate event and passing it to MyController.handleEvent():

<div data-controller="bridge--search"
     data-action=”bridgework:queryDidUpdate->my-controller#handleEvent”>
  <input type=”search” name=”query” />
</div>

I’m not 100% sure on this one yet, I’m still working through it.

---

What do you think of the Bridgework name? I was also considering BridgeKit but didn’t love the capital K as much. Leave a comment below, I’d love some feedback!