Skip to content

feat: added flow wrapper for cache#15

Open
ethan-berg-kr wants to merge 3 commits into
mainfrom
cache-flow-wrapper
Open

feat: added flow wrapper for cache#15
ethan-berg-kr wants to merge 3 commits into
mainfrom
cache-flow-wrapper

Conversation

@ethan-berg-kr
Copy link
Copy Markdown
Collaborator

feat: adding a wrapper to allow clients to receive all updates to a given cache via a StateFlow

Copy link
Copy Markdown
Collaborator

@krogrammer krogrammer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copied over my comments from the original PR

Comment thread cache/src/main/java/com/kroger/cache/internal/CacheFlowWrapper.kt Outdated
Comment thread cache/src/main/java/com/kroger/cache/CacheFlowWrapper.kt
Comment thread cache/src/main/java/com/kroger/cache/internal/CacheFlowWrapper.kt Outdated
Comment thread cache/src/test/java/com/kroger/cache/internal/CacheFlowWrapperTest.kt Outdated
public class CacheFlowWrapper<T>(
private val cache: SnapshotPersistentCache<T>,
private val scope: CoroutineScope,
) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API seems like it could be improved by making this class implement MutableStateFlow directly. That would allow for an asFlow() extension on SnapshotPersistentCache:

fileCache.asFlow(scope).collect { it }

public fun <T> SnapshotPersistentCache<T>.asFlow(scope: CoroutineScope): MutableStateFlow<T> {
    return CacheFlowWrapper<T>(this, scope)
}

And all of the MutableStateFlow members could be implemented by delegating to the internal _cacheValueState

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I gave that a shot, and the only issue I can see with it is that the original implementation has logic around waiting for the first value to be read before updating the flow with anything else. Emit is suspending, and can work the same way, but tryEmit and needing to override value as a var with a public setter that's not suspending is where there is an issue.

For tryEmit we could just return false until initialization is complete, but It's trickier for just assigning a new value to the value var. it could throw an error I suppose, but that feels like it's introducing unnecessary risk.

alternatively it could just implement SharedFlow, but that would remove the ability to just read the value directly if needed. Or maybe that could be a separate wrapper for a different use case.

@ethan-berg-kr ethan-berg-kr changed the base branch from alpha to main April 9, 2026 22:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants