Feature request: TableCell highlighting about functionaltabledata

[g-Off]

Contemplating this one a bit now. If we hook into it with an action similar to SelectionAction you lose a bit of the type safety in that your view would come through as a UIView and would require a force/optional cast to the expected type before digging into the view hierarchy to manipulate backgroundColor.

I wonder if we should change the signature of the update function:
func update(cell: UITableViewCell, in tableView: UITableView)

to be more along the lines of
func update(cell: UITableViewCell, in tableView: UITableView, context: UpdateContext)

UpdateContext could then be something along the lines of

enum UpdateContext {
    case default // the regular old case of just updating the data
    case selection // maybe?
    case highlight
    case ... // I don't know, are there more cases? begin a drag? move? edit mode initiated on the table...
}

FunctionalTableData Delegate/Datasource's would then, on highlight/select/etc calls trigger this.
HostCell would then have its own implementation of this and the cellUpdater function would be extended to support the context argument. This would then mean that the update function would be passed a concrete view type, the state, and the context.

I think this could be introduced in a backwards compatible way as well.

@runmad thoughts?
@raulriera could use your opinions here as well

[runmad]

I really like that suggestion!

With the actions, I definitely feel like we're missing parts of what comes for free with UITableViewCell callbacks on selection and highlighting within the view itself.

I think starting with selection/highlighting seems appropriate for now and more closely resemble
func setSelected(Bool, animated: Bool) and func setHighlighted(Bool, animated: Bool).

Is this somewhat related to #54?

[g-Off]

The highlight delegate methods are:

func tableView(_ tableView: UITableView, shouldHighlightRowAt indexPath: IndexPath) -> Bool
func tableView(_ tableView: UITableView, didHighlightRowAt indexPath: IndexPath)

returning false on the shouldHighlightRowAt "halts the selection process and does not cause the currently selected row to lose its selected look while the touch is down"

didHighlightRowAt might be called after the highlight is finished, which is possibly too late and the highlight animation on the cell may have finished. I don't currently have time at the moment to dig into the nuances of these functions vs UITableViewCell's func setHighlighted(_ highlighted: Bool, animated: Bool). If the delegate one triggers at the right time then that's the better one to tie into as it would no longer require any special implementation on the cell level. If the setHighlighted is the right spot then we'd need to have our TableCell implementation (that backs HostCell) implement that behaviour (a bit more annoying but doable as well).

And yeah, this could be somewhat related to #54 as it could be one of the cases used in the Context enum

[runmad]

That's true. I suppose this ties in a bit with functionality in FunctionalTableData+Cells.swift

[raulriera]

The Context change will be a good addition, but complexity for implementing a cell will skyrocket. Now we are dealing with many more "states". I would be inclined for some magic here, an UIView extension for shouldHighlightItem and didHighlightItem that HostCell automatically call to all its subviews.

This will have to work with highlight from CellStyle to shut it down I assume, otherwise we will have multiple "highlight" API

[runmad]

@g-Off @raulriera any thoughts on this?

[runmad]

Looks like iOS 13 changes the way highlighting works, which affects CellConfigs

[raulriera]

Looks like iOS 13 changes the way highlighting works

How did they change?

[runmad]

For example:

Selections don't show up here using functionalTableData.select(keyPath:animated:)

and when tapping: