Skip to content
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

Shorten usage of Fields in include, where, and orderBy API functions #150

Closed
6 tasks done
vestrel00 opened this issue Dec 25, 2021 · 5 comments
Closed
6 tasks done
Assignees
Labels
enhancement New feature or request

Comments

@vestrel00
Copy link
Owner

vestrel00 commented Dec 25, 2021

Problem

The suggested usage of Fields in the library results in too long statements due to redundancy of using Fields.. For example,

.where((Fields.Email.Address startsWith "a") and (Fields.Email.Address endsWith "gmail.com"))

While this is the only way Fields can be used by Java users, we can shorten it for Kotlin users. Actually, Kotlin users can already remove the redundant calls to Fields. this by using run on it,

.where(Fields.run { (Email.Address startsWith "a") and (Email.Address endsWith "gmail.com") })

However, it is not obvious and requires consumers to still use Fields. once.

Consumers could also import all properties of Fields. However, it could cause a lot of name clashes between the name of the field (e.g. Email) and the name of the entity (e.g. Email).

Solution

Remove the need for consumers to use Fields.run (and other equivalent field sets), in include, where, and orderBy API functions.

Usage for Kotlin users would look like,

.where{ (Email.Address startsWith "a") and (Email.Address endsWith "gmail.com") }

This also gets rid of the need for consumers to know that they should be using Fields to begin with, even though it is mentioned in the documentation.

We can take this a step further by providing extensions for a field sets,

.where{ Email { (Address startsWith "a") and (Address endsWith "gmail.com") } }

And even further by providing extensions for individual fields,

.where{ Email.Address { startsWith("a") and endsWith("gmail.com") } }

Checklist

  • Add the extra functions to all APIs
  • Update sample Kotlin code in API class docs
  • Update all relevant howto pages
  • Update README
  • Update medium and dev.to blog code snippets
  • Update sample app usages
@vestrel00 vestrel00 added the enhancement New feature or request label Dec 25, 2021
@vestrel00 vestrel00 self-assigned this Dec 25, 2021
@vestrel00 vestrel00 changed the title Shorten usage of Fields in include, where, and orderBy API functions Shorten usage of Fields in where API functions Dec 25, 2021
@vestrel00 vestrel00 changed the title Shorten usage of Fields in where API functions Shorten usage of Fields in include, where, and orderBy API functions Dec 25, 2021
@vestrel00 vestrel00 pinned this issue Dec 25, 2021
@vestrel00 vestrel00 unpinned this issue Dec 25, 2021
@jayasuryat
Copy link
Contributor

Hi @vestrel00,
(Continuing conversation from here)

Would this thread be appropriate to continue the above mentioned conversation?

@vestrel00
Copy link
Owner Author

vestrel00 commented Jan 3, 2022

Hey! Welcome 🔥 Anywhere is fine. This is okay. If you'd like, you can start a new discussion https://github.com/vestrel00/contacts-android/discussions/new it's all up to you. I have no preference 😁

For my reference and other contributors, this is about this thread in Reddit; https://www.reddit.com/r/Kotlin/comments/rtxfdm/comment/hr19srb/?utm_source=share&utm_medium=web2x&context=3

@jayasuryat
Copy link
Contributor

jayasuryat commented Jan 3, 2022

Started a new discussion (#162) to continue on this.

@vestrel00
Copy link
Owner Author

Based on that discussion, I'm reopening this issue and assigning it to you @jayasuryat! Please delete my 500 lines of code here and replaced it with your 2 lines of code!!! GENIUS!

@vestrel00
Copy link
Owner Author

Included in release; https://github.com/vestrel00/contacts-android/releases/tag/0.1.10

vestrel00 added a commit that referenced this issue Jan 25, 2022
* #150 Added some initial documentation about the Contact lookup key

* #140 Added lookup key when logging Contacts table using the debug module extensions

* Started a section for Contact ID vs LOOKUP_KEY in the DEV_NOTES

* #140 Added more dev notes on lookup keys after researching the behavior after linking contacts

* #140 Completed documentation

* #140 Added lookupKey property to Contact entity

* #140 Added ContactLookupKey extensions, finalized documentation, and updated sample app to use lookup key instead of ID
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants