@acemarke.dev should data that does not drive UI (it's not consumed by any component) live inside redux store?

but for one or two preferences it's just overthink

at the end of the day I think that user preferences should be considered client state and treated as synchronous. The asynchronicity of its persistency it's just a technicality that should be handled by a middleware

yes, pretty much all persistency apis on react native are async.
But it's not like a server where data could be modified by external actors 🤔. So I guess there is no need for refetching (stale Infinity), but it's convenient to use modification for persistency. Something similar to this

I get the sidebar example, that is completely synchronous and with known starting value. But I'd say that something that needs async persistence logic for storing and retrieval is more of a grey-area

I'm not a fan of video tutorials. Are all the topics of these videos already covered with the same granularity on expo docs.expo.dev?

Tried downloading an older version of Google Translate from 2024. With that the translation works correctly.
Looks like it's a regression from Google side.

can confirm

Using navigation.setOptions({ headerRight }) just to update parts of the header feels counterintuitive. It breaks the declarative component model React encourages. I'd rather just render <Header /> in my JSX and control everything with props/state like normal — it’s clearer and easier to maintain.

non hai idea di quante volte l'ho notato in ufficio.
Da brividi.

meow

context: views with opacity set to 0 do not receive click events on iOS but does on Android.