Closed arkivanov closed 6 months ago
The recent updates primarily involve the removal of the @ExperimentalMviKotlinApi
annotation across various components in the mvikotlin-extensions-coroutines
and mvikotlin-extensions-reaktive
modules. This change signifies a stabilization of features previously considered experimental, affecting both the core libraries and associated tests.
File Path | Change Summary |
---|---|
.../extensions/coroutines/*.kt and .../extensions/reaktive/*.kt |
Removed @ExperimentalMviKotlinApi from various classes and functions. |
.../extensions/coroutines/*Test.kt and .../extensions/reaktive/*Test.kt |
Removed @OptIn(ExperimentalMviKotlinApi::class) from test classes. |
sample/.../shared/details/store/DetailsStoreFactory.kt |
Removed @file:OptIn(ExperimentalMviKotlinApi::class) and associated imports. |
🐰✨ A hop, a skip, a code base flip, No more tags of "experimental" on our trip. Stabilize, harmonize, under open skies, Code rabbits cheer as old caution flies! 🎉🐇
sample/coroutines/shared/src/commonMain/kotlin/com/arkivanov/mvikotlin/sample/coroutines/shared/details/store/DetailsStoreFactory.kt (14)
`1-1`: Package declaration is appropriate and follows Kotlin conventions. --- Line range hint `3-12`: Imports are correctly organized and relevant to the functionality of the `DetailsStoreFactory`. --- Line range hint `14-14`: Function `detailsStore` is well-named, clearly indicating its purpose to create a `DetailsStore` instance. --- Line range hint `16-16`: The use of `internal` visibility modifier is appropriate, ensuring encapsulation within the module. --- Line range hint `18-18`: Parameters `database`, `mainContext`, `ioContext`, and `itemId` are well-defined, providing all necessary context for the store's operation. --- Line range hint `20-20`: The use of delegation by the `Store` interface using `by create<...>` is a clean and effective way to implement the `DetailsStore` interface. --- Line range hint `22-22`: Initialization of the store with a simple bootstrapper (`SimpleBootstrapper(Unit)`) is straightforward and appropriate for many use cases. --- Line range hint `24-24`: The `coroutineExecutorFactory` is used correctly to define the store's executor. This is a key part of integrating coroutines with the MVI architecture. --- Line range hint `26-26`: Definition of `ExecutorScope.save` function within the executor factory is a good use of local functions to encapsulate behavior that does not need to be exposed externally. --- Line range hint `28-28`: Use of `launch` with `ioContext` for database operations adheres to best practices by offloading I/O operations to an appropriate coroutine context. --- Line range hint `30-30`: Handling of actions and intents within the executor is clear and logically structured, facilitating easy understanding and maintenance. --- Line range hint `32-32`: The reducer function is well-implemented, with clear handling of different message types to mutate the state appropriately. --- Line range hint `34-34`: The use of sealed classes for messages (`Msg`) enhances type safety and makes the state management more predictable. --- Line range hint `36-36`: Type alias for `ExecutorScope` is a clean way to simplify type signatures throughout the code.mvikotlin-extensions-reaktive/src/commonMain/kotlin/com/arkivanov/mvikotlin/extensions/reaktive/ReaktiveExecutorDsl.kt (8)
`1-1`: Package declaration correctly specifies the location within the project structure. --- `3-3`: Import statements are appropriate and necessary for the functionality provided in this file. --- `5-5`: The documentation comment provides a clear explanation of the `reaktiveExecutorFactory` function's purpose and usage. --- Line range hint `7-7`: Function `reaktiveExecutorFactory` is correctly implemented to provide a factory for `Executor` instances, using the provided configuration block. --- Line range hint `9-9`: The private `executor` function is a good design choice, encapsulating the logic for executor creation and keeping the public API clean. --- `11-11`: The `ExecutorBuilder` class is well-designed, providing a clear and flexible way to build executors with custom behavior. --- `13-13`: Use of inline functions with reified type parameters in `onIntent` and `onAction` methods allows for type-safe handling of intents and actions, which is crucial for the correctness of the executor behavior. --- `15-15`: The implementation of `ExecutorImpl` class is robust, correctly handling the execution of intents and actions, and managing its lifecycle through the `DisposableScope`.
Closes #96.
Summary by CodeRabbit
@ExperimentalMviKotlinApi
annotation across various components, indicating a stabilization of these features in the library.@OptIn(ExperimentalMviKotlinApi::class)
annotation, reflecting changes in the experimental status of features.