In certain situations, library or shared code may wish to retrieve a Mavericks ViewModel while only having access to a parent type of the runtime one at the declaration site.
These changes allow callers of the delegates in MavericksExtensions.kt to provide a KClass parameter specifying the actual runtime class of the desired MavericksState, rather than always using the type of the declared property.
Because such MavericksViewModel parent types are often generics with a bound on the MavericksState class, a common pattern is to declare a covariant type for the state, such as ParentViewModel<out ParentState>. In order to support this without intermediate variable declarations or type casts, we also need to add support for covariant state types to several Mavericks features, such as withState() calls, the mockSingleViewModel() family of calls, and the selectSubscribe() calls.
Also attempts to add unit tests covering these covariant use cases.
In certain situations, library or shared code may wish to retrieve a Mavericks ViewModel while only having access to a parent type of the runtime one at the declaration site.
These changes allow callers of the delegates in MavericksExtensions.kt to provide a
KClass
parameter specifying the actual runtime class of the desiredMavericksState
, rather than always using the type of the declared property.Because such
MavericksViewModel
parent types are often generics with a bound on theMavericksState
class, a common pattern is to declare a covariant type for the state, such asParentViewModel<out ParentState>
. In order to support this without intermediate variable declarations or type casts, we also need to add support for covariant state types to several Mavericks features, such aswithState()
calls, themockSingleViewModel()
family of calls, and theselectSubscribe()
calls.Also attempts to add unit tests covering these covariant use cases.
See https://github.com/airbnb/mavericks/issues/551 for more details.