I don't see any need for a pattern there - just access the object normally (.-thing js/window)

how do I handle tests ?

if they don't run in the browser and I would like to pass a shape of that object.

my use case is for an integration MetaMask browser extension that adds window.ethereum. I believe I can create the ethereum object via a librar if need be

my concern is that if I depend on (.-ethereum js/window) I get all these references to a global, external object scattered across the app

but I am new so I don't know any better, just asking some questions to understand why

It depends on where you use the values. If you use them in event handlers, you can create a cofx that injects their values. If you use them in subs, then I think the only approach would be to store the value in the app-db, make the subs use that value, and update the value using events from JS. At are events at least for some of the properties of window.

If you care only about testing and don't care about keeping your subs pure, then you can just wrap all access to js/window in a function that can be mocked or reconfigured in tests.

thanks, it's a bit more clear now. I would like to have them pure. I like a stable floor that doesn't dissappear from underneath me when I'm coding 🙂

Custom coeffects (for sync reads) and effects (for async reads and any writes) are the pure solution to this problem. @U011NGC5FFY And @U2FRKM4TW is correct that you you'd need to put values in app-db to use in subs. In fact, sub functions should be a function of their inputs (i.e. query-v for signal fns, and app-db or other subs for computation fns) otherwise it breaks the subscription cache and sub deduplication. As equality of two subs is if the query-v is = .

I'd hook the windows events and cause a dispatch

(.onresize js/window #(dispatch [:window-resize (.innerHeight js/windows) ...]))

In the event handler I'd update the value in app-db. Then the subscription will fire.