NibReusable should have bundle as an optional parameter about reusable

[AliSoftware]

Another thing you could do in your non-standard localisation case is to create your own protocol:

protocol LocNibReusable: NibReusable {
  static var nibName: String { get }
}
extension LocNibReusable {
  /* reasonable default implementations */
  static var nibName: String { return String(describing: self) }
  static var nib: UINib { return UINib(nibName: nibName, bundle: nil) }
}
extension UITableView {
  func register<T: LocNibReusable>(cellClass: T.Type, bundle: Bundle?) {
    let nib = UINib(nibNamed: cellClass.nibName, bundle: bundle)
    self.register(nib, forCellReuseIdentifier: cellClass.reuseIdentifier)
  }
}

[AliSoftware]

What about the suggestion on my second comment? Maybe mixing that with your idea of customBundle?

protocol LocNibLodable: NibLodable {
  static var customBundle: Bundle? { get }
}
extension LocNibLoadable {
  static var nib: UINib {
    return UINib(named: String(describing: self), bundle: customBundle)
  }
  // And depending on your needs, you could also provide a default implementation for customBundle
  /* static var customBundle: Bundle? { return bundleForCustomLoc() } */
}

And then you'd just have to make your tableViewCells conform to LocNibLoadable instead of just NibLodable 😉

[kuyazee]

Your second comment, why didn't I think of that 😆. I should have just done that from the beginning.

Thank you.

[AliSoftware]

Hi,

Thanks for the suggestion, but I fail to see how this would fit efficiently with the Mixin pattern Reusable is providing:

• The core idea of Reusable is to avoid having to call tableView.register(nib, forCellReuseIdentifier: name) and to avoid having all those strings prone to typos in your code.
• So as you can see in the README, the main benefit of Reusable with UITableViewCell is to be able to call tableView.register(SampleTableViewCell.self), with no Strings involved, so no risk of typos (with the compiler telling you at compile time if you did one)

So for your use case and the example you provide, I fail to see how you actually make use of Reusable in the example at the bottom of your post… or how you would use Reusable and pass a bundle as parameter if you did use Reusable. Because:

• Even if we made the bundle as a parameter for determining the nib, like you suggest with static func nib(bundle: Bundle?), the way Reusable works is you'll not be the one calling that nib function. It will be called when you call tableView.dequeueReusableCell(for: indexPath) as SampleTableViewCell
• I don't see how you'd pass the bundle you want in that call to tableView.dequeueReusableCell(for: indexPath) as SampleTableViewCell
• And if your plan was to pass that bundle at registration time and not dequeue time (which would indeed probably make more sense), this means that you'll not use Reusable anymore when you call tableView.register(SampleTableViewCell.self)…
• or did you expect to modify that definition of func register<T> in Reusable here to take a bundle too? That seems like pulling the strings quite far and changing the API for something only a few people will use (custom localisation being quite unusual and non-standard), "polluting" it for others, right?

I'm not closed to changing the API to allow new usages and concepts, but it should only be for use cases that are common and standard; otherwise if we start that road, people are then gonna ask to be able to pass other parameters (like a value to indicate which nib to use depending on other parameters, if you have one cell class backed by multiple XIBs and want to use one or the other depending on some condition… and we'd go down the rabbit hole)

---

So overall, I think making nib take a bundle as parameter is probably not the best option. What I'd suggest you instead would be to have a global property (or better, a static var on Bundle) returning the current bundle for the custom localisation your app is currently using. Then use that to implement var nib: UINib { … } in your Reusable cells:

// Extension to access the .lproj bundle corresponding to the current custom localization
extension Bundle {
  static var currentLocalization: Bundle {
    let currentLocale = UserDefaults.standard.string(for: "CurrentLocale")!
    let path = Bundle.main.path(forResource: currentLocale, ofType: "lproj")!
    return Bundle(path: path)!
  }
}

// Example cell
class SampleTableViewCell: UITableViewCell, NibLoadable {
  static var nib: UINib {
    return UINib(nibName: String(describing: self), bundle: .currentLocalization)
  }
}

// Usage example
tableView.register(SampleTableViewCell.self)
let cell = tableView.dequeueReusableCell(for: indexPath) as SampleTableViewCell

[kuyazee]

The example you gave is actually how I'm implementing things at the moment.

And if your plan was to pass that bundle at registration time and not dequeue time (which would indeed probably make more sense), this means that you'll not use Reusable anymore when you call tableView.register(SampleTableViewCell.self)… or did you expect to modify that definition of func registerin Reusable here to take abundle` too? That seems like pulling the strings quite far and changing the API for something only a few people will use (custom localisation being quite unusual and non-standard), polluting it for others, right?

Yes I was expecting that the definition of register edited or overloaded to take a bundle. But after thinking about it that wouldn't work well like you said.

Maybe one of these can work

• Create a configuration file for Reusable where if I set a custom bundle the library would use that on static var nib: UINib instead of me needing to declare it on every NibReusable subclass. Because that would just be
• Add a static var customBundle: Bundle? on NibLoadable which will be used by the static var nib: UINib variable.

I don't know I'm not sure what the best course of action here.