FunctionalTableData v2.0 Ideas

[krbarnes]

I've been thinking about some potential changes to this library that could mean breaking small API changes. I don't have working implementations of these things so it's a list of dreams right now.

1. Cell and Row IDs should be AnyHashable instead of String
   • In our apps we're converted typed IDs to Strings and back to IDs when we need to use them when there's no real reason that the ID couldn't be used directly.
2. Codable TableSection and CellConfig
   • This would allow us to persist our current state easily and write a snapshot style test assert that a section matches the recorded encoded section.
3. Use Difference Kit instead of our custom diffing algorithm.
   • We occasionally have to debug TableSectionChangeSet to find the cause of an issue. The code's difficult to understand and we aren't getting the benefit of the number of eyes that DifferenceKit has.

[robinsenior]

I've been messing around with an alternative to CombinedCell that makes it easier to compose multiple cells. Any interest in adding it here?

[alinebee]

Another +1 for DifferenceKit: it handles the case where sections are moving at the same time as cells within those sections, which will ordinarily throw a UIKit exception. FTD's differ doesn't handle this, which was causing a crash on one of our screens, requiring some hacky workarounds with keys that made the animation worse.

[robinsenior]

Any chance we could revisit https://github.com/Shopify/FunctionalTableData/pull/65 ?

[raulriera]

Now that we can just use an URL in the Playgrounds app (or I just TIL today about it), we can make this a playground book as well

Check out Create Your Own Swift Playgrounds Subscription from #WWDC18 https://developer.apple.com/wwdc18/413

[ghost]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 3 days if no further activity occurs.

[ghost]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 3 days if no further activity occurs.

[boourns]

Often there are stateless cells in a UI, for example a static header. Perhaps these could be first class citizens instead of having to provide a dummy state?

[boourns]

Different thought: could the scope of the library be much smaller by vending cells instead of views to the update closure, and getting rid of the all the cell styling structs? Then the API would only cover the things that FunctionalTableData needs to know to respond to the UITableViewDelegate methods that query information about the cell (like can it be selected, moved, etc)

I'm not advocating that would necessarily be better, maybe having the cell styles as a declarative struct leads to less bugs.. just an idea

[alinebee]

Then the API would only cover the things that FunctionalTableData needs to know to respond to the UITableViewDelegate methods that query information about the cell (like can it be selected, moved, etc)

I haven't thought this through fully, but it smells like it'd be possible to do this and build the existing cell styling system on top of it, by providing a default implementation of the state updater that calls into other implementations on conforming state types.

Passing the cell to the updater would eliminate a major pain point we have at the moment, where the constraints of the cell itself cannot be customized by the state updater - leading to kludges like encoding layouts as a generic parameters to the cell type.

[runmad]

Add UISwipeActionsConfiguration

[g-Off]

I'm closing this issue as I've moved most of the items to individual issues. The only thing I haven't brought over is

Stateless Cells (from @boourns) and Cell Style/View Updater related discussion: https://github.com/Shopify/FunctionalTableData/issues/120#issuecomment-462363076 https://github.com/Shopify/FunctionalTableData/issues/120#issuecomment-462382072

I left these out because this seems like a discussion about HostCell and I think what you're talking about here can be done by having a different UITableViewCell subclass. The "kludges like encoding layouts as a generic parameters to the cell type" is specific to HostCell to make it more general purpose and flexible. However, you can easily create another type of cell that has specific layout associated with it, or can be adjusted however. If you're keen on this I'd suggest taking HostCell and "forking" it and trying out some experiments.