-
Notifications
You must be signed in to change notification settings - Fork 553
chore: Move flask filter logic from ViewModels to Services #1345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Earlier, ViewModels were building flask filter queries themselves and passing them to Services. This was not good because this leaked the data retrieval logic into the ViewModels. Only the Services should be concerned with data retrieval and they should abstract out that logic. This change moves the logic into Services where it belongs. Fixes: fossasia#1344
e3cb419
Resolve codacy issues |
Codacy is complaining that using This is actually a false positive since I'm filtering out the |
There's no false positive about nulls in pure kotlin. If it is non null, then you won't need null asserted call Your filter isn't understandable at the language level. Use order.event.id?:0 |
I've the following concern in using Suppose that somehow, a
IMHO even though the above situation will never arise and from a purely functional point of view, both are identical; semantically, |
Null asserted calls are code smell. Don't use the Elvis operator but remove the null asserted calls |
I've fixed the issue. Now, my code is using |
app/src/main/java/org/fossasia/openevent/general/event/EventService.kt
Outdated
Show resolved
Hide resolved
@AnEnigmaticBug Please resolve conflicts |
1 similar comment
@AnEnigmaticBug Please resolve conflicts |
@AnEnigmaticBug Please resolve conflicts. It has been a month |
@liveHarshit Please fork and resolve conflicts |
@iamareebjamal can i take up on this ? |
@iamareebjamal i need to fix conflicts only i guess? |
Yes |
@iamareebjamal close this |
Fixes #1344
Changes: Earlier,
ViewModel
s were building flask filter queries themselves and passing them toService
s.This was not good because this leaked the data retrieval logic into the
ViewModel
s. Only theService
s should be concerned with data retrieval and they should abstract out that logic.This change moves the logic into
Service
s where it belongs.