Skip to content

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

Closed
wants to merge 3 commits into from

Conversation

AnEnigmaticBug
Copy link
Contributor

Fixes #1344

Changes: 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.

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
@fossasia fossasia deleted a comment Mar 19, 2019
@fossasia fossasia deleted a comment Mar 19, 2019
@fossasia fossasia deleted a comment from AnEnigmaticBug Mar 19, 2019
iamareebjamal
iamareebjamal previously approved these changes Mar 20, 2019
nikit19
nikit19 previously approved these changes Mar 20, 2019
@AnEnigmaticBug AnEnigmaticBug dismissed stale reviews from nikit19 and iamareebjamal via e3cb419 March 21, 2019 13:06
@fossasia fossasia deleted a comment Mar 21, 2019
@fossasia fossasia deleted a comment Mar 21, 2019
@fossasia fossasia deleted a comment from AnEnigmaticBug Mar 21, 2019
@iamareebjamal
Copy link
Member

Resolve codacy issues

@AnEnigmaticBug
Copy link
Contributor Author

Codacy is complaining that using !! is unsafe in this line: it.filter { order -> order.event != null }.map { order -> order.event!!.id }.

This is actually a false positive since I'm filtering out the null elements before I map the list.

@fossasia fossasia deleted a comment Mar 21, 2019
@fossasia fossasia deleted a comment Mar 21, 2019
@fossasia fossasia deleted a comment from AnEnigmaticBug Mar 21, 2019
@iamareebjamal
Copy link
Member

iamareebjamal commented Mar 21, 2019

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

@AnEnigmaticBug
Copy link
Contributor Author

I've the following concern in using order.event.id?:0:

Suppose that somehow, a null managed to by-pass filter(even though it is impossible)

  1. The !! version communicates the message that this is an illegal state which shouldn't have occurred.
  2. The ?: version communicates that it's ok to add 0 to the list of event ids if we encounter a null.

IMHO even though the above situation will never arise and from a purely functional point of view, both are identical; semantically, !! is more appropriate than ?: in this case.

@iamareebjamal
Copy link
Member

Null asserted calls are code smell. Don't use the Elvis operator but remove the null asserted calls

@AnEnigmaticBug
Copy link
Contributor Author

I've fixed the issue. Now, my code is using mapNotNull which applies map's transformation and then takes only the non-null results.

@fossasia fossasia deleted a comment Mar 21, 2019
@fossasia fossasia deleted a comment Mar 21, 2019
@fossasia fossasia deleted a comment from AnEnigmaticBug Mar 21, 2019
@iamareebjamal
Copy link
Member

@AnEnigmaticBug Please resolve conflicts

1 similar comment
@iamareebjamal
Copy link
Member

@AnEnigmaticBug Please resolve conflicts

@iamareebjamal
Copy link
Member

@AnEnigmaticBug Please resolve conflicts. It has been a month

@iamareebjamal
Copy link
Member

@liveHarshit Please fork and resolve conflicts

@aggarwalpulkit596
Copy link
Contributor

@iamareebjamal can i take up on this ?

@aggarwalpulkit596
Copy link
Contributor

@iamareebjamal i need to fix conflicts only i guess?

@iamareebjamal
Copy link
Member

Yes

@aggarwalpulkit596
Copy link
Contributor

@iamareebjamal close this

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.

chore: Move flask filter query logic from ViewModels to Services
4 participants