View controller visit proposal extensions

[olivaresf]

Briefly discussed here: https://github.com/joemasilotti/TurboNavigator/pull/53/files#r1329138612

The use case for this behavior is making sure that the "view-controller" property in the Path Config matches a native ViewController. So, for example if we have:

{
  "rules": [
      {
        "patterns": [
          "/recipes/*"
        ],
        "properties": {
            "view-controller": "RecipeViewController",
        }
      },
  ]
}

A view controller may identify itself by implementing TurboIdentifiable:

 class RecipeViewController: UIViewController, TurboIdentifiable {
    
    static var viewControllerPathConfigIdentifier: String { "RecipeViewController" }
}

And so, a TurboNavigator's handleProposal(proposal:) delegate may work something like this:

func handle(proposal: VisitProposal) -> ProposalResult {
        
        switch proposal.viewController {
            
        case RecipeViewController.viewControllerPathConfigIdentifier:
            return .accept(RecipeViewController.new)
            
        default:
            return .accept

        }
    }

Naming isn't final. Open to any suggestions.

[joemasilotti]

This looks great! I think all that's missing is documentation on how/why to use the new property.

Does the demo app need to be updated, too?

[olivaresf]

This looks great! I think all that's missing is documentation on how/why to use the new property.

Sweet. I'll add some documentation.

Does the demo app need to be updated, too?

I'll check but all of this should be backward compatible and shouldn't affect the demo app.

[olivaresf]

I've added documentation and checked the demo project. 👍🏻

[joemasilotti]

Thanks @olivaresf! Two questions/requests:

First, do we want to identify the controller by its full name? I remember @jayohms mentioning that if we rename the controller via a refactor that could get messy. Maybe we use "recipe" in the example instead?

Second, I think we want documentation in the README, too. Especially in the section that explains native controllers.

But your doc additions to the code itself makes me want to flesh out more documentation there, too! It makes me wonder where we want the bulk of the documentation - the README, a Docs/ directory, or right in the code. The path we are on now is starting to spread everything out which is asking for it to get out of sync eventually.

What do you think? I bring this up to make sure it is aligned with turbo-ios for when this eventually gets upstreamed.

[olivaresf]

First, do we want to identify the controller by its full name? I remember @jayohms mentioning that if we rename the controller via a refactor that could get messy. Maybe we use "recipe" in the example instead?

This is more regarding the example configuration file in my comments, correct? Since the protocol expects a String, users can choose whatever they want. I've no problem with renaming it to recipe or recipeVC or something like that. As long as the identifier matches the config, there would be no issues regardless of the name we choose.

Second, I think we want documentation in the README, too. Especially in the section that explains native controllers.

Agreed! I realized I forgot to update the ReadMe this morning. I'll update it too. 👍🏻

What do you think? I bring this up to make sure it is aligned with turbo-ios for when this eventually gets upstreamed.

I agree it could get out of sync. 🤔 I think of the ReadMe as more of an introductory document, which could include less explanation and more examples, whereas I've found code documentation being more useful the more more extensive it is because you are not context switching when coding. Let me update the ReadMe and I can come up with a proposal.

[olivaresf]

I've updated the ReadMe.

I think for now having documentation in both places is useful. If we wanted to add more code comments, it'd be good to find a unifying strategy, but for now I think it's not a big deal.

[joemasilotti]

This is great, thanks @olivaresf! I just made a few copy and code formatting tweaks. I'll merge when CI passes.

What is the next step based on #53? I'm excited how fast this is moving!