Table header/footer nib can't be made Reusable

[mac-cain13]

Reported by @sdevos:

Table header/footer nib can't be made Reusable, because a reuse identifier can only be set on a UITableViewCell not on other UIView subclasses. Therefore R.swift will not generate a NibResource that implements Reusable.

This makes that the helper method func registerNibForHeaderFooterView<T: NibResource where T: Reusable, T.T: UIView>(nibResource: T) never can be called.

We should consider an alternative, for example:

• Make the function take nibResource: T and a reuseIdentifier: String
• Make it possible to make the rootview from the xib implements a protocol so it can provide an identifier

[justinmakaila]

I'm not sure if this helps, but you can drag and drop a UITableViewCell into your nib, and change it's class to a custom class that inherits from UITableViewHeaderFooterView. This allows you to set the reuse identifier on the xib.

Using this solution, I'm currently facing this issue:

let headerView = tableView.dequeueReusableHeaderFooterViewWithIdentifier(R.nib.homeFeedSectionHeaderView)

With an error that reads "Cannot convert value of type '_R.nib._HomeFeedSectionHeaderView' to expected argument type 'String'."

I think it's due to the generic constraints on dequeueReusableHeaderFooterViewWithIdentifier, which is expecting a type of UITableViewCell

[ilyapuchka]

What about for headers/footers conventionally generate reuse identifier with value of the nib name? Personally for me it's a default approach to use class name both for nib name and for reuse id. I think that is also true for most of devs.

Alternative approach could be to provide an extension to UITableViewHeaderFooterView that adds @IBInspectable property for identifier (and stores it as associated object). Then after user first runs R.swift and includes generated code he/she will be able to set the reuse identifier in IB. Then on next build R.swift will be able to parse xib and extract that value (stored in user defined attributes node). If adding such extension is not an option then users most likely will have it anyway (or R.swift documentation can recommend to add such extension to enable reuse id generation) so R.swift can still inspect user defined attributes basing on some naming convention.

@justinmakaila That will work, but I had problems with auto-layout. Header was not rendered correctly, particularly it was not filling table width completely. Anyhow I suppose it's more like a hack way and can break with any new release of Xcode.

[robinkunde]

I +1 the suggestion to synthesize a reuse identifier with an appropriate prefix.

[setoelkahfi]

Currently I'm facing this issue that my headerview is blank after I reload the tableview. I end up to setup the headerview everytime I reload the tableview.