Mirego-base-setup 3 of X: MVVM pattern #44
Conversation
|
🦀 Requesting reviewers for this pull request:
🦀 Mentionning users for this pull request:
|
| import okio.Path.Companion.toPath | ||
| import okio.buffer | ||
|
|
||
| class ApolloGraphQLDiskDataSource<R : ApolloGraphQLDataSourceRequest<T>, T : Query.Data>( |
There was a problem hiding this comment.
I think we should instead use Apollo's built-in normalized cache instead of implementing our own caching solution.
There was a problem hiding this comment.
Does any of our projects use the Apollo cache now? I now we had issues with it in the past
There was a problem hiding this comment.
In transat, we used normalized cache in the beginning but switched to Trikot datasources afterwards. If I remember correctly, there were 2 reasons:
- Noticeable performance issues (might be fixed now I suppose, since this was in mid-end of 2022)
- There were no easy way to manage states (Loading, Error, Data but also Pending with data, Error with data, expiring data, etc...))
I feel like, for now, we should stick to Trikot datasources in the boilerplate until more projects uses normalized cache (and can vouch that everything works great!)
| import kotlinx.serialization.json.Json | ||
| import kotlin.time.Duration.Companion.minutes | ||
|
|
||
| open class GenericDataSource<T>( |
There was a problem hiding this comment.
Shouldn't these generic datasources be provided directly in the com.mirego.trikot.datasources library?
There was a problem hiding this comment.
Agreed that we need those in the lib
sdetilly
force-pushed
the
feature/mirego-base-setup-mvvm
branch
from
67ebe16 to
a83f0c9
Compare
📖 Description
Add our basic MVVM pattern
View, ViewModel, UseCase, Repository
Also added datasources and Apollo to query a Mirego GraphQL api
🦀 Dispatch
#dispatch/kmp