Refactor instructions banner

[frederoni]

This is another take on #1085 using a View Model approach. It also fixes #792

An InstructionsBannerViewModel that handles the logic and an InstructionsBannerViewState which encapsulates the state has been added.

Using a custom instructions banner could look something like:

let viewModel = InstructionsBannerViewModel { (viewModel, state) in
    v.maneuverView.step = state.maneuverViewStep
    v.primaryLabel.instruction = state.primaryInstruction
    v.secondaryLabel.instruction = state.secondaryInstruction
    v.distanceLabel.text = String(state.distanceRemaining)
}
        
viewModel.update(for: routeProgress)

• Refactor so that we don't have to pass in a DistanceLabel to the view model
• Fix the remaining tests
• Audit access control, bridgability, and write documentation
• Merge or cherry-pick the InstructionPresenter from Hides delimiters in banner when surrounded by loaded shield images #1046 /cc @akitchen

@mapbox/navigation-ios

[bsudekum]

I wonder if

let viewModel = InstructionsBannerViewModel { (viewModel, state) in
    v.maneuverView.step = state.maneuverViewStep
    v.primaryLabel.instruction = state.primaryInstruction
    v.secondaryLabel.instruction = state.secondaryInstruction
    v.distanceLabel.text = String(state.distanceRemaining)
}

Is still a lot of domain knowledge for the developer to manage. Could this be simplified even further?

[frederoni]

It's actually a pretty common design pattern. As long as we provide examples, I don't think our power users using the custom UI would struggle with this. Not sure how we could simplify this further. 🤔

[JThramer]

Hmm, I'm not sure I see the benefit of this. It is a more formal pattern, but I don't see why we need to have a formal view model, instead of just offering two methods on InstructionsBannerView.

• One is a direct setter method, that allows you to set the primaryLabel or secondaryLabel (for example) directly from a string, or instruction, or whatever. If you want the label to say "Willy Wonka's Chocolate Factory", this is what you use.
• The other is a method that takes the correctly-scoped model-object (say, a RouteLegProgress), and encapsulates the appearance logic (currently in RMVC) to set appropriate values for primaryLabel and secondaryLabel, etc. This is what you use when you just want to feed updates from the routing service (routeController) to the UI components.

If we had multiple routing services, each with their own model schema, then I could totally see the use-case for formalized view-models. But as our codebase stands right now, it just seems like overkill, and tedious overkill at that.

Is there an architectural flaw in #1085 that necessitates this PR?

/cc @bsudekum @1ec5

[bsudekum]

In addition to @JThramer, I feel like the amount of code + knowledge added here is pretty high. @frederoni what do you think the drawbacks are to #1085? What I like about #1085 is the simplicity.

[JThramer]

Going to mark this "Request Changes" until we pow-wow about this PR's fate.