You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Using FUISortedArray with the FUIIndexTableViewDataSource / FUIIndexCollectionViewDataSource #273
I'm looking to combine the usage of FUISortedArray and FUIIndexTableViewDataSource as follows:
let sortedArray = FUISortedArray(query: query, delegate: nil) { (lhs, rhs) -> ComparisonResult in
return lhs.compare(rhs)
}
let dataSource = FUIIndexTableViewDataSource(collection: sortedArray, data: data, view: tableView) { tableView, indexPath, snapshot in
/* ... */
}
I can see there is a constructor available on FUITableViewDataSource that accepts a FUICollection , but there doesn't seem to be one for FUIIndexTableViewDataSource.
This is not currently possible. FUIIndexArray and friends are entirely separate from FUIArray to the point where they don't even share a common superclass, and this is intentional--though their use cases are similar, their dependencies and behaviors are vastly different (specifically FUIIndexArray has an extra layer of complexity). FUIIndexArray does, however, take an FUIArray to manage its indexes, so we could update the class to allow users to control the array dependency and then you could pass in a sorted array instead of a regular one.
There are a few things that need to happen for this to work:
The indexed collection and table view data sources should drop the views from their initializers and move to the bind(to: view) pattern that the other data sources have adopted to accommodate the FUIIndexArray change.
After this users would be able to change their index array content order by changing the order of the indexes, but they wouldn't be able to re-order the contents of the index array independently of the indexes (which is not something I think we want to support anyway).
I will get to this eventually because it strikes me as an artificial limitation of the indexed classes, but until then PRs are always welcome.
On 29 Mar 2017, at 22:03, Morgan Chen ***@***.***> wrote:
This is not currently possible. FUIIndexArray and friends are entirely separate from FUIArray to the point where they don't even share a common superclass, and this is intentional--though their use cases are similar, their dependencies and behaviors are vastly different (specifically FUIIndexArray has an extra layer of complexity). FUIIndexArray does, however, take an FUIArray to manage its indexes, so we could update the class to allow users to control the array dependency and then you could pass in a sorted array instead of a regular one.
There are a few things that need to happen for this to work:
FUIIndexArray needs to stop subscribing to index updates on initialization
The indexed collection and table view data sources should drop the views from their initializers and move to the bind(to: view) pattern that the other data sources have adopted to accommodate the FUIIndexArray change.
After this users would be able to change their index array content order by changing the order of the indexes, but they wouldn't be able to re-order the contents of the index array independently of the indexes (which is not something I think we want to support anyway).
I will get to this eventually because it strikes me as an artificial limitation of the indexed classes, but until then PRs are always welcome.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
FUIIndexArray needs to stop subscribing to index updates on initialization
Will this look a lot like 78? Where users will have to call observeQuery to kick things off?
The indexed collection and table view data sources should drop the views from their initializers and move to the bind(to: view) pattern that the other data sources have adopted to accommodate the FUIIndexArray change.
Hello, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. If it is still relevant, leave a comment to keep it open.
This issue will be closed in 15 days if no further activity occurs.
Activity
morganchen12 commentedon Mar 29, 2017
This is not currently possible.
FUIIndexArrayand friends are entirely separate fromFUIArrayto the point where they don't even share a common superclass, and this is intentional--though their use cases are similar, their dependencies and behaviors are vastly different (specificallyFUIIndexArrayhas an extra layer of complexity).FUIIndexArraydoes, however, take anFUIArrayto manage its indexes, so we could update the class to allow users to control the array dependency and then you could pass in a sorted array instead of a regular one.There are a few things that need to happen for this to work:
FUIIndexArrayneeds to stop subscribing to index updates on initializationbind(to: view)pattern that the other data sources have adopted to accommodate theFUIIndexArraychange.After this users would be able to change their index array content order by changing the order of the indexes, but they wouldn't be able to re-order the contents of the index array independently of the indexes (which is not something I think we want to support anyway).
I will get to this eventually because it strikes me as an artificial limitation of the indexed classes, but until then PRs are always welcome.
codemodouk commentedon Mar 29, 2017
coreywiley commentedon Jun 8, 2017
I'm up for taking this on.
@morganchen12
Will this look a lot like 78? Where users will have to call
observeQueryto kick things off?And this change will use this pattern: 142
Let me know if this looks right.
morganchen12 commentedon Jun 8, 2017
Yep, sounds about right. Thanks for taking this on!
github-actions commentedon Jul 8, 2026
Hello, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. If it is still relevant, leave a comment to keep it open.
Thank you for your contributions.
russellwheatley commentedon Aug 3, 2026
Closing out, this work isn't planned. If anyone wishes to open a PR, I'm happy to review it.