why does datepicker in material3 (and similar components) have state as parameter instead of state flowing down events up?

I'm not sure I understand the question. Having state as a parameter is what enabled state to flow down. Could you describe what API you would have expected?

from the documentation and codelabs I did, it was always said you should send immutable state down and event should fire up. I would probably do Component(state, onStateChange = { newState -> state = newState })

I've wondered about that too. There is no clear "date selected" callback, we have to do a LaunchedEffect on the state to detect the changes. It's cumbersome

I don't have a problem with it being a seperate interface

I get what you mean now. There are other components that have similar APIs. Some examples of components that I work with a lot are: 1.

Horizontal/VerticalPager

which accepts a

PagerState

parameter. You don't get a callback when a page in the pager is selected. Instead you need to observe properties on

PagerState

itself (like

currentPage

). You also use the same state to perform actions like scroll to a specific page. 2.

ModalBottomSheetLayout

which accepts a

ModalBottomSheetState

. You don't get callbacks when the bottom sheet is expanded/hidden. You observe properties for this. Again, you use the same state object if you want to perform actions like expand/collapse the sheet.

I do agree that this approach is fine for Pager, since we don't really care about the moment of change, just the final state

You could consider hoisting that state entirely to the ViewModel, like we often do with the state that drives TextField as suggested here. Then your ViewModel won’t need any callbacks for this, it will just know about it, right?

sure, but what about when you need to save it to local storage? how would you know when to do it if you don't have a specific submit button?

Save what to persistent storage, the date selection before it’s used somewhere?

if you have a datepicker for example and you want to persist it as soon as state changes. hoisting to viewmodel only helps with saving state for ui

Persist it where and why? That's what I'm focusing on now.

persist it in local storage for example

That state has a .Saver implementation, so you can use that to save it to and from a bundle, so you can use rememberSaveable or savedstatehandle in your ViewModel

the point is that there is no event that flows up, that you could react to if you pass state as argument to composable

Persist the transient date picking in local storage as the user is picking from a dialog? Why? Just trying to understand

it's not about the datepicker. it's about the general pattern of passing state as parameter. I was just wondering why the material3 components use it instead of state down events up

We've done a full loop in this conversation

I think it is a valid question: When should you use callbacks for events versus a state holder?

I'd imagine you'd always want some way to react to the date selected outside of just updating other UI. Let's say I'm making a calendar app. When the user selects a date, I want to update the event's date in the database. This would be easiest if DatePicker took a state variable and an onDateChanged. It seems silly to have a date picker that only affects other UI without persistence.

Yeah, but do you want to save to persistent storage on each date change? Usually this date picker is shown in a dialog, and after you’re done selecting, you press an OK button in order to confirm that choice. That’s when I’d save to persistent storage by taking what the current date picker state looks like. Are you sure you can’t do that and you want to persist each change as the user is going through the dates and is possibly selecting many dates in the process?

I guess the easiest way is to use the dialog and get the state in the confirmButton onClick, but that's an extra button press.

How else does your user dismiss the dialog which shows the date picker?

The new

BasicTextField2

also has only

state

argument without

onChange

lambda 🤔 Maybe it is new “this is the way” :mandalorian: 🤔 https://developer.android.com/reference/kotlin/androidx/compose/foundation/text2/package-summary

And it exposes a

forEachTextValue

which allows you to do something per new state change. Which internally is literally just

textAsFlow().collectLatest(block)

where

textAsFlow()

is just

fun TextFieldState.textAsFlow(): Flow<TextFieldCharSequence> = snapshotFlow { text }

. So exactly what we discussed above here too, taking the state that the date picker exposes, and observe its changes. SnapshotFlow and flows in general give you this super clean api on how to do this.

@Stylianos Gakis I understand where you're coming from. However it still doesn't answer the question: how do we decide when to use event callbacks versus observable properties in the state object? I think we need an answer that is general and not specific to DatePicker.

Yeah that I can agree with. Me included, I don’t think I can intuitively decide when to do that and when it’d be an overkill. With that said, it seems to me like when things start to become more involved is when you can go for such a state holding object. If you look at the internals of the date picker you’ll see it’s doing quite a lot of stuff. But of course “when it’s too complicated” isn’t a good enough description, and I’d love to get a better understanding for it too.

Also I don't agree with some of your conclusions above: 1. It is not always a good choice to hoist Compose-UI specific state to ViewModels. This is especially true if you are using multiplatform a Presenter layer but not Compose UI multiplatform. 2. Based on 1, there still ought to be a good way to know when a Date has been selected without the user clicking on a Save button. The DatePicker API already provides a way for this but it is more verbose than a simple event callback.

The point of it not being easy to listen to see changes gets repeated a lot. Do you find that doing a snapshotFlow on the state and collecting those changes something that is too complicated vs a lambda?

val fooState = rememberFooState(
  initialState,
  { newState ->
    useNewState(newState)
  }
)

vs

val fooState = rememberFooState(initialState)
LaunchedEffect(Unit) {
  snapshotFlow { fooState.internalState }.collect { newState ->
    useNewState(newState)
  }
}

Do you find that doing a snapshotFlow on the state and collecting those changes something that is too complicated vs a lambda?

It is fine in isolation in one place but I fear it might become tedious and repetitive if you have several components all of which expect you to LaunchedEffect + snapshotFlow + collect every time you want to react to a simple change.

One thing that can happen is needing multiple sources of truth for when there would be asynchronicity when trying to have just a single source of truth. Let’s say you have a slider updating some user preference that is being saved to disk. You can try having a single source of truth (the disk) for the entire round trip: on changing the slider position, update the value on disk, wait for that update to propagate, and update the UI. However, that full round trip is asynchronous, and it might look janky or glitchy if the UI is lagging behind what the user is trying to do. Instead, you can sort of split out the source of truth: 1. The persisted value on disk, which you load to set the initial value display in the slider. 2. The “in-flight”, user-is-currently-editing state that will follow the user’s actions synchronously without glitchiness. But now you intentionally have created a separate source of truth that you need to reconcile with the persisted value: an “in-flight” state that you need to sync that back to the persisted value on disk. That’s where the

LaunchedEffect

comes in. And you could replace “on disk” with “over the network” and now the

LaunchedEffect

becomes even more important. The “awkwardness” raises important questions like “how often should I try to update the value?” “what happens if the update fails due to some I/O error?” “what happens if the value was updated somewhere else?” “what scope should the

LaunchedEffect

be launched in which impacts when an update is cancelled?” A lot of those considerations can depend on your exact use case. Maybe you can synchronize the value immediately always, or maybe you have an “OK” and “Cancel” to confirm a change