Using FUISortedArray with the FUIIndexTableViewDataSource / FUIIndexCollectionViewDataSource

[codemodouk]

Hi,

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.

Is this possible?

Thanks

[morganchen12]

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.

[codemodouk]

Thanks for the detailed response. I will take a deeper dive into this and see what my options are.

…

Sent from my iPhone

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.

[coreywiley]

I'm up for taking this on.

@morganchen12

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.

And this change will use this pattern: 142

Let me know if this looks right.

[morganchen12]

Yep, sounds about right. Thanks for taking this on!