Summary:
**Context**
Recently an IGListKit experiment was introduced, `IGListExperimentPerformUpdatesWithoutDeferringCATransactionCommit`. When enabled, we opt to no longer defer a call to `[CATransaction commit]`, because it could feasibly end a different transaction than intended. In practice, this was leading to issues with `UIViewPropertyAnimator`, where deffered commits were ending in-progress animators.
**This Change**
The results we have seen from enabling this fix show no changes to performance and stability, so this seems safe to roll out. This change removes the experiment, and enables the new, non-deffered behavior.
Reviewed By: lorixx
Differential Revision: D20120169
fbshipit-source-id: 0473652020a250d67b02b860fb74c73e43615aef
Summary:
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1428
We kept getting an error as the following:
```
- ERROR | [OSX] unknown: Encountered an unknown error (The platform of the target `App` (macOS 10.11) is not compatible with `IGListSwiftKit (4.1.0)`, which does not support `macOS`.) during validation.
```
Looks like IGListSwiftKit did not support macos, wondering why this is the case here.
Potentially this error was introduced in this PR: https://github.com/Instagram/IGListKit/pull/1388
cc natestedman who might know the context here
The solution here is to lint the specs separately in travis, so that for IGListSwiftKit we only lint against ios and tvos. And the other podspecs will still lint against on all platform, including the macos.
Reviewed By: natestedman
Differential Revision: D20036436
fbshipit-source-id: 5406cef1825fc4c157fee9ca5856ace81df0508d
Summary:
We were using the iVar version of the `_displayDelegate`, but turned out a lot of product callsite just manually override the `displayDelegate` instead of use `self.displayDelegate = self`.
Let's use the self.displayDelegate instead.
Reviewed By: bdotdub
Differential Revision: D20037298
fbshipit-source-id: fa860adfa88cd088f39718279983acd32e90b478
Summary:
There is a KP in IGListBindingSingleSectionController that we need to override the `displayDelegate` in order to track the displayingCell for performant update, when the section controller is not visible.
With the newly refactoring in how IGListSectionController handles the displaying events, IGListBindingSingleSectionController can now override the willDisplay/endDisplay calls without manually adding itself as the `displayDelegate`, the behavior works as before.
Differential Revision: D19973670
fbshipit-source-id: 1f9fec1bf88aa8755c163c636ebb49b377e6873c
Summary:
Previously, IGListDisplayHandler took over the sectionController's displayDelegate and invoke directly.
We have requirement in other cases where we want to control the displayDelegate invokation, e.t. Subclass of IGListSectionController can listen to the willDisplay/endDisplay events and do other processing.
Moving the displayDelegate invokation inside IGListSectionController would allow us to have better control on the invokation timing.
Differential Revision: D19973669
fbshipit-source-id: 33d23bc7efb235d2e1ed99737200e56bb320b678
Summary:
When a section/cell is reloaded, UICollectionView actually calls:
1/ WillDisplay (new cell)
2/ DidEndDisplay (old cell)
So if we set `_displayingCell` in willDisplay call, then set it to nil in didEndDisplay, we would just have a nil cell. Thus we need to make sure the cell in `didEndDisplay` match with the previous `_displayCell` to avoid nil-ing ourselves out.
Reviewed By: alanzeino
Differential Revision: D19906734
fbshipit-source-id: 5217908ae99d488a2af5ff3f90ef8e021774acda
Summary:
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1418
This assert causes crashes on debug builds. While it's known that this algorithm is slow with a large number of items to work through, it doesn't seem to have been an issue for most when working with IGListKit. Removing this assertion to avoid crashes for others.
Reviewed By: bdotdub
Differential Revision: D19251924
fbshipit-source-id: c0e78d3963544b949bed823bdac9b39529ca5f9f
Summary:
Originally we want to update the cell when the SectionController is asked to update to a new value, that's pretty much what the experiment `singleItemSectionUpdates` is for inside `IGListAdapterUpdater`.
However, we should not request any cell during the initial setup, otherwise it would trigger cell to render in a wrong time, in particular we shouldn't call
```
UICollectionViewCell *cell = [self.collectionView cellForItemAtIndexPath:indexPath];
```
as the data source set up is not ready, and it can get crashy to compare the initial dataSource(nil) to the valid data source(IGListAdapter), which doesn't make sense.
So tl;dr is do not access cell during the initial data source setup. We might need to audit other callsite that might have violate this invariant.
Solution here is to rely on the willDisplay/endDisplay API from `IGListDisplayDelegate` so that we can set/unset the displaying cell here before we configure the cell with the updated data. This change is also safe as it's protected by `_enabledCellConfigurationDuringUpdate` which defaults to be NO.
= Facebook =
Also currently the `singleItemSectionUpdates` is only setup for Inbox thread-bump useage for now. So I added a `enabledCellConfigurationDuringUpdate` to properly gate it behind QE so that we have a safer exit here.
Reviewed By: maxolls
Differential Revision: D19332040
fbshipit-source-id: cbca7a63b0486c053ceabe759ce316f5d841fef5
Summary:
The `cellClass` parameter was still documented, but no longer present in the method signature.
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1412
Reviewed By: lorixx
Differential Revision: D19178421
Pulled By: iperry90
fbshipit-source-id: 17e69db2c5d52581bfd205b5557c6564cf0e5673
Summary:
## Changes in this pull request
Initial suggested implementation for https://github.com/Instagram/IGListKit/issues/1387.
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1388
Reviewed By: lorixx
Differential Revision: D18687735
Pulled By: natestedman
fbshipit-source-id: f9cc70ced3f788771fd3f0443b56befbedb04166
Summary: Swift 5 came out a while ago, we should definitely be targeting it.
Reviewed By: lorixx
Differential Revision: D19141252
fbshipit-source-id: d6f8fc5209e721a8b28e569855b5e3cc8b8c3431
Summary:
**Context**
When performing non-animated updates, `IGListKit` does so by beginning a `CATransaction` before `performBatchUpdates:`, and ending it in the completion block. While this disables animations for the collection view updates, it is feasible that some other changes might be bundled into the same transaction, given that we have no guarantee of the completion block being called inline.
It seems that this is happening in practice and occasionally disrupting `UIViewPropertyAnimator` animations, forcing the completion immediately.
**This Change**
To fix this issue, we can commit the transaction inline. Here we use `performWithoutAnimation:`, although it's possible that this is just a wrapper around `CATransaction` calls anyway.
Because the change may have unknown side effects, this change is gated by an experiment.
Reviewed By: maxolls
Differential Revision: D19150307
fbshipit-source-id: f7cff46ac7141609f42caafaf69bad71a980ad29
Summary: These were added in internal builds (Buck) but broke the external build (Xcode).
Reviewed By: lorixx
Differential Revision: D19141251
fbshipit-source-id: 7dc891ee227e24561e6e4cb20c9c6d20dead5e2d
Summary:
= Problem =
Most of the UICollectionView/List UI only needs to deal with 1 dimensional array of data. The current N section N item setup is a big more complicated for most use case who only deals with 1 dimensional array.
In fact, the IGListDiff algorithm works pretty with 1 dimensional array. Then inside `IGListAdapterUpdater`, we do a lot changes to ensure UICollectionVie do not crash:
1. Convert section moves -> delete+insert;
2. Convert section reload -> delete+insert;
This results in the animation limitation for the UI updates, we lose the move animation support by UICollectionView and the updates for delete+insert does not look great.
= Solution =
Since direct inbox or direct message list view only uses N section, with single item setup.
We don't need to do crazy changes like changing moves->delete+insert, and use -reloadSections etc. for updates.
We can just use whatever the IGListDiffingResult returns and be done with it.
More context, see my post and the Better Animation part I listed in the group: https://fb.workplace.com/groups/iglistkit/permalink/1009885999357045/
Reviewed By: iperry90
Differential Revision: D18856355
fbshipit-source-id: 50cf93a6903f0c86c44e5e1289384efe8db9acc1
Summary:
= Problem =
Most of the UICollectionView/List UI only needs to deal with 1 dimensional array of data. The current N section N item setup is a big more complicated for most use case who only deals with 1 dimensional array.
In fact, the IGListDiff algorithm works pretty with 1 dimensional array. Then inside `IGListAdapterUpdater`, we do a lot changes to ensure UICollectionVie do not crash:
1. Convert section moves -> delete+insert;
2. Convert section reload -> delete+insert;
This results in the animation limitation for the UI updates, we lose the move animation support by UICollectionView and the updates for delete+insert does not look great.
= Solution =
Hence I am proposing to use simple **Single Item** Section Controller, and we can apply the diffing result directly to the UICollectionView, which is much simpler.
However, for the inline section update, we need to support update at the right timing: inside -didUpdateObject:, and now we want to get back the existing cell, and apply data to it.
Ideally, `IGListSingleSectionController` is the right call but `IGListSingleSectionController` is not subclassable and we would also need to change the way -didUpdateObject: works in that class.
Hence I am building this `IGListBindingSingleSectionController`, which only contains single item, and it can update/bind the cell whenever item is updated.
Reviewed By: iperry90
Differential Revision: D18942974
fbshipit-source-id: 539fbe2b72691b649e3ae3d8ed725006bc54b705
Summary: The window frame needs to be big enough so that the cells are rendered fine with the bounds.
Reviewed By: candance
Differential Revision: D18949587
fbshipit-source-id: 1374bc3bab6892aafea5bbab9e8af3399e966344
Summary:
In the Feed view, all the -isEqualToDiffable: implementation only checks the pk, a.k.a the identifier.
Let's mimic that behavior.
Reviewed By: calimarkus
Differential Revision: D18714064
fbshipit-source-id: e1fe9624da2997ecc7ca9b684ddd471d77b7564c
Summary: I want to reuse this collection view update code in next diff, let's move it to a Helper file to support code sharing.
Reviewed By: calimarkus, iperry90
Differential Revision: D18714061
fbshipit-source-id: a85e8576226276fcab90ea1d2ed23aac5501aa17
Summary:
…uld show empty view
## Changes in this pull request
Basically we can use the existing _itemCountIsZero like all the other usage, and it's faster since it stopped early, compared to before we loop through all the sectionController.numberOfItems and sum up.
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [ ] I added tests, an experiment, or detailed why my change isn't tested.
- [ ] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1400
Differential Revision: D18687637
Pulled By: lorixx
fbshipit-source-id: bcdc57ba43b86cd0ed639ffaab9ae0493fd2f844
Summary:
## Changes in this pull request
Issue fixed: #
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [ ] I added tests, an experiment, or detailed why my change isn't tested.
- [ ] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1399
Differential Revision: D18687660
Pulled By: lorixx
fbshipit-source-id: 3195aec55ffdcea1457a09c74313329559caa5ad
Summary:
## Changes in this pull request
`Examples/Examples-iOS/Pods/Pods.xcodeproj/project.pbxproj`
`Examples/Examples-tvOS/Pods/Pods.xcodeproj/project.pbxproj`
this change just Xcode 11.2 generated.
This pr aim to remove useless `IGSystemVersion` file.
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [ ] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1396
Reviewed By: lorixx
Differential Revision: D18638299
Pulled By: iperry90
fbshipit-source-id: 0b6583f1210e5d1570dd672eed8c59901d6785f6
Summary:
## Changes in this pull request
Get this fix and make it ready for 4.0 release.
### Checklist
- [ ] All tests pass. Demo project builds and runs.
- [ ] I added tests, an experiment, or detailed why my change isn't tested.
- [ ] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [ ] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1393
Reviewed By: iperry90
Differential Revision: D18618773
Pulled By: lorixx
fbshipit-source-id: 0360c36d85dc5db15d7e08bdf68ec9c8be992499
Summary:
As title, let's prepare the 4.0 release with the version bump.
1. Change the Source/Info.plist to have 4.0.0 for CFBundleShortVersionString.
2. Manually update any .md files that used the old release versions.
3. Run `./scripts/setup.sh` to re-update all the pods and the Example projects.
Reviewed By: natestedman
Differential Revision: D18616823
fbshipit-source-id: ca0f2a09cdd9ab592c2cb002fe923e195ce3ab12
Summary:
## Changes in this pull request
This updates the Podfile to use the specs CDN instead of the git checkout, which is more performant (and the default with CocoaPods 1.8 and higher).
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1386
Reviewed By: lorixx
Differential Revision: D18572204
Pulled By: iperry90
fbshipit-source-id: d3b721aaff92b18efeef31282cb9204055baec21
Summary:
## Changes in this pull request
Updated the link to RxIGListKit as the current one points to a dead end. Simple documentation update, no code changes.
Issue fixed: #
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1375
Reviewed By: bdotdub
Differential Revision: D18525301
Pulled By: iperry90
fbshipit-source-id: 650c6828b5a9ba256d2aa6b0c1abb27d3de43a8c
Summary:
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1385
I attempted to work the two frameworks into a single podspec, but it didn't really work that well. Instead, let's just split them into two podspec files - this should work fine, and more closely follows the Carthage/Xcode behavior.
This should address #1382. Note that the attached project does need to be edited, because we also need to manually specify the `IGListDiffKit` pod location. This issue will go away with the release of 4.0.
Reviewed By: iperry90
Differential Revision: D18449843
fbshipit-source-id: 2750aee1ba39d21b9f1b3521ea8911929ae728b1
Summary: We need this for the `--include-podspecs` flag used in the next commit.
Reviewed By: iperry90
Differential Revision: D18450156
fbshipit-source-id: 88b12e5e8d22fbd3ec4fe0fb51aa6f4426216f25
Summary: This allows us to have a single declaration of the version in the `Info.plist`, and have it automatically synced to the podspec. I'm going to split the podspecs as I did it wrong (#1382) when splitting the libraries, so this avoids having three places where the version is declared.
Reviewed By: iperry90
Differential Revision: D18449842
fbshipit-source-id: 2991180ee14003b8ebe1f4ef601036404315dfd6
Summary:
## Changes in this pull request
Add Swift name annotation `ListAdapterDelegate` to `IGListAdapterDelegate`. The breaking change is written in the `CHANGELOG.md` for the `4.0.0` release
Issue fixed: https://github.com/Instagram/IGListKit/issues/1115
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1116
Reviewed By: bdotdub
Differential Revision: D18278551
Pulled By: iperry90
fbshipit-source-id: db9d1910fc4be7ffa723ee291a9c65db0fd217c0
Summary:
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1377
This splits the diffing-only components from `IGListKit` out into a separate library, `IGListDiffKit`, allowing them to be used independently of the rest of `IGListKit`. We've found that the diffing components of the library are useful independently of the rest of the `UICollectionView` infrastructure, and separating the libraries allows apps to take advantage of those components without paying the full binary size cost of `IGListKit`. The diffing components are available as a subspec in Cocoapods, and as an independent framework in Carthage and direct Xcode project import (i.e. Git submodules).
This is a breaking change, necessitating a major version bump, although it should have only minor impact for projects using the umbrella header `IGListKit.h`, as that header continues to import the diffing utilities. In particular, for a project using Cocoapods and importing `IGListKit.h`, there should be no code changes required.
Reviewed By: calimarkus
Differential Revision: D18114249
fbshipit-source-id: 363b5a427e32800bbc6e82f897230963b4167245
Summary:
We don't use nokogiri directly in our library, but it found its was into our Gemfile.lock. I'm bumping the version in the Gemfile.lock because the version it's calling for has a security vuln: https://github.com/sparklemotion/nokogiri/issues/1915. When I tried setting up this library from a github clone, so I imagine others may be running into this and wasting time on it as well.
Another solution here would just be to remove nokogiri from our Gemfile.lock entirely. I don't think we use it directly anywhere, and was just included in the lock because it happened to be in someone's environment at the time of the lock file creation.
Reviewed By: joetam
Differential Revision: D18046184
fbshipit-source-id: de6263bb24783988545a77cb67ee66c9697820de
Summary:
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1376
Our [builds](https://travis-ci.org/Instagram/IGListKit) have been failing since `IGListStackedSectionController` was removed in [D17200801](D17200801)/[1355](https://github.com/Instagram/IGListKit/pull/1355). The error message in our Travis logs points to something related to `IGListStackedSectionController` causing the error:
```
X error: /Users/travis/build/Instagram/IGListKit/Source/Internal/IGListStackedSectionControllerInternal.h: No such file or directory
** BUILD FAILED **
The following build commands failed:
CpHeader /Users/travis/build/Instagram/IGListKit/Source/Internal/IGListStackedSectionControllerInternal.h /Users/travis/Library/Developer/Xcode/DerivedData/IGListKitExamples-cfbxdbnpimeeplcoaiqrlyrrqjxn/Build/Products/Debug-iphonesimulator/IGListKit/IGListKit.framework/PrivateHeaders/IGListStackedSectionControllerInternal.h
(1 failure)
```
Pretty sure the issue here is that the `xcodeproj` files were not rebuilt after deleting these files, which meant they were pointing to files that no longer existed, which caused the build to fail. I was able to fix this issue by running our `setup.sh` script, which regenerated the `xcodeproj` files.
Reviewed By: bdotdub
Differential Revision: D18064465
fbshipit-source-id: d07586a99d4bbb9346bdda0752dbd613eb1b6d03
Summary:
Issue: The `NSIndexPath` level updates are really tricky because they don't go through the diffing process. It's up to the caller to make sure that the inserts/deletes/moves all add up to the final number of items. And it's not uncommon that 2 different updates will try to change the same `NSIndexPath` at the same time, which can cause headaches and crashes. For example, if we insert/delete the same `NSIndexPath` twice in the same update pass, we end up with 2 inserts and 1 delete, because we remove duplicated deletes. This causes an `NSInternalInconsistencyException` since things don't add up at the end.
Fix: Lets also remove duplicate `NSIndexPath` inserts to balance things out. In the future, it would be nice to get rid of this API entirely and have everything go through the diffing.
Reviewed By: lorixx
Differential Revision: D17423776
fbshipit-source-id: 62fdf5bd521a915e984e8de180c74858f7ae7ef4
Summary:
## Changes in this pull request
Issue fixed: #
### Checklist
- [ ] All tests pass. Demo project builds and runs.
- [ ] I added tests, an experiment, or detailed why my change isn't tested.
- [ ] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [ ] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1366
Differential Revision: D17401484
Pulled By: lorixx
fbshipit-source-id: 2fda3a2b36d88a712f2853774eed5987793db26c
Summary:
* Issue: `[IGListAdapter scrollToObject ...]` currently calls `[collectionView layoutIfNeeded]` before scrolling which creates the current visible cells that will no longer be visible after the scroll. This causes perf issues when we scroll immediately after creating the view controller.
* Fix: Instead of asking the layout object for the attributes, lets go throught the `UICollectionView`. So if the attributes are not ready, the `UICollectionView` will call `-prepareLayout`, return the attributes, but doesn't generate the cells just yet.
Differential Revision: D17326459
fbshipit-source-id: 745942225e0311fea7c3efb07ac1e8b8e0a82996
Summary:
* Issue: Calling `[UICollectionView layoutAttributesForSupplementaryElementOfKind...]` with an indexPath that doesn't have a supplimentary view.
* Cause: `IGListCollectionViewLayout` always returns a non-nil `UICollectionViewLayoutAttributes` when calling `layoutAttributesForSupplementaryViewOfKind` which tells the `UICollectionView` that it's fair game to ask the dataSource for a supplementary view at the indexPath. But when it does, the section controller could return nil, which throws an expection.
In the Apple docs about `[UICollectionViewDataSource collectionView:viewForSupplementaryElementOfKind:atIndexPath:]`
> This method must always return a valid view object. If you do not want a supplementary view in a particular case, your layout object should not create the attributes for that view.
https://developer.apple.com/documentation/uikit/uicollectionviewdatasource/1618037-collectionview?language=objc
* Fix: Just like `UICollectionViewFlowLayout`, if the supplementary view size is empty, lets return a nil attribute.
Reviewed By: Ziewvater
Differential Revision: D17326461
fbshipit-source-id: 507e98f43e951216cf2eafe2449f87df25439e11
Summary:
* Fix `prefetchingEnabled` which is only available in iOS 10. Not entirely sure why this hasn't been an issue before.
* Re-enable the scrollToObject tests by avoiding the safeAreaInsets
Reviewed By: lorixx
Differential Revision: D17326458
fbshipit-source-id: c99ee6f8bcf91aca427d3122fdefe67d6c99055b
Summary:
## Changes in this pull request
Remove the redundant __IPHONE_11_0, because the minimum requirement is Xcode 9.0+ now.
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1351
Differential Revision: D17200815
Pulled By: lorixx
fbshipit-source-id: 25705856cf26d5c215ed956802ab1022c98cbca0
Summary:
### Changes in this pull request
* Improve compilation time by reducing unnecessary compilation dependencies
* More clean code
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1358
Differential Revision: D17200761
Pulled By: lorixx
fbshipit-source-id: 9c6bca4d3d5e2e4b35125c7a12e483d58993c4e8
Summary:
## Changes in this pull request
Update to use `QoS` and take higher priority for responsiveness and energy efficiency.
Following the guideline in the doc [Energy Efficiency Guide for iOS Apps](https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/PrioritizeWorkWithQoS.html).
It's better to use `User-initiated` QoS in `Background Diffing` because it focuses on "Work that the user has initiated and requires immediate results".
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1363
Differential Revision: D17200745
Pulled By: lorixx
fbshipit-source-id: 4b9b2159f06edeed92e79bac771fe7b89f6d5708
Summary:
## Changes in this pull request
Update `README` installation version to the latest stable version `3.4.0`
### Checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I added tests, an experiment, or detailed why my change isn't tested.
- [x] I added an entry to the `CHANGELOG.md` for any breaking changes, enhancements, or bug fixes.
- [x] I have reviewed the [contributing guide](https://github.com/Instagram/IGListKit/blob/master/.github/CONTRIBUTING.md)
Pull Request resolved: https://github.com/Instagram/IGListKit/pull/1354
Differential Revision: D17200807
Pulled By: lorixx
fbshipit-source-id: 733f8c65e4eff7b0498c0425354f5951fd5d8569
