Skip to content

Using FUISortedArray with the FUIIndexTableViewDataSource / FUIIndexCollectionViewDataSource #273

Closed

Description

@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

Activity

  1. morganchen12 commented on Mar 29, 2017

    @morganchen12
    Contributor

    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.

  2. self-assigned this
    on Mar 29, 2017
  3. codemodouk commented on Mar 29, 2017

    @codemodouk
    Author
  4. coreywiley commented on Jun 8, 2017

    @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.

  5. morganchen12 commented on Jun 8, 2017

    @morganchen12
    Contributor

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

  6. reopened this on Jun 9, 2026
  7. github-actions commented on Jul 8, 2026

    @github-actions

    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.

    Thank you for your contributions.

  8. russellwheatley commented on Aug 3, 2026

    @russellwheatley
    Member

    Closing out, this work isn't planned. If anyone wishes to open a PR, I'm happy to review it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions