Toast is persisted through configuration changes #592
Conversation
…ough configuration changes. To achieve this, the ToastHostState has to rely on a callback rather than suspending function. This is a breaking change in the API.
| @@ -49,7 +49,7 @@ import kotlinx.coroutines.launch | |||
|
|
|||
| public interface ToastData { | |||
| public val message: String | |||
| public val icon: @Composable (() -> Painter)? | |||
| public val iconName: IconName? | |||
There was a problem hiding this comment.
I would really like the name to be part of "Painter" in icons (e.g. by encapsulating the painter in our own object or similarly...), it would allow to stick with usage of Icons even here, internally it would derive the name and back through your mapping, but that's just a wish I guess.
There was a problem hiding this comment.
How would you deserialize the name back to the painter - especially in the case of your own set of icons?
| @@ -49,7 +49,7 @@ import kotlinx.coroutines.launch | |||
|
|
|||
| public interface ToastData { | |||
| public val message: String | |||
| public val icon: @Composable (() -> Painter)? | |||
| public val iconName: IconName? | |||
There was a problem hiding this comment.
How would you deserialize the name back to the painter - especially in the case of your own set of icons?
|
|
||
| @Composable | ||
| public fun rememberToastHostState( | ||
| onDismiss: () -> Unit = {}, |
There was a problem hiding this comment.
I'd say onDismiss should receive the ToastData. +-
|
Closing this PR. Surpassed by #596 where we can continue our discussion. |
The currently displayed toast and any queued toasts are persisted through configuration changes.
To achieve this, the ToastHostState has to rely on a callback rather than suspending function. This is a breaking change in the API.
refs #576