Uses native implementation when available #43
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rafaelnobrekz
force-pushed
the
native-when-available
branch
from
77c8122
to
0333e6d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
Description
This change aims to use the native diffable data source implementation whenever possible (which at this point is 90% of times). This avoids some small API discrepancies and bugs that have been fixed.
Related Issue
#42
Motivation and Context
This library has always (wisely) aimed at closely mimicking the native API because of its temporary nature. Ideally we don't want to have to use backports. But while we can't target the API we need, they are invaluable to adopt newer tech. In the case of DiffableDataSources though, we must use the backport even for the latest OS versions, which is unfortunate. The "sister" library I met along with this one was IBPCollectionViewCompositionalLayout, and it very neatly and transparently uses the backport only when the native API is not available. This is the aim of this PR. To make the transition to fully native as seamless as possible. Just remove the shims when you can and you're good to go.
Impact on Existing Code
I have wrapped native API under the existing code, so as far as I can understand there is no impact. I simply carry a native instance when the OS allows, and skip the backport one. I introduced internal init methods that enable forcing the backport so the tests could focus on testing the backports instead of what's available on the simulator running the tests. The public API is still the exact same.