New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FunctionalTableData v2.0 Ideas #120
Comments
I've been messing around with an alternative to |
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. |
Any chance we could revisit #65 ? |
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 |
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. |
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. |
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? |
Different thought: could the scope of the library be much smaller by vending cells instead of views to the 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 |
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. |
I'm closing this issue as I've moved most of the items to individual issues. Stateless Cells (from @boourns) I left these out because this seems like a discussion about |
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.
The text was updated successfully, but these errors were encountered: