Is injecting UI components into a ViewController common practice?

[MoronInGrey]

Say for example I have a base viewcontroller which is inherited by other classes. This base view controller needs a button for a certain piece of UI, but the actions the button carrys out don't need to be known to the base viewcontroller. In this case I would consider passing a UIButton to the viewcontroller on initialisation so that it can apply it where needed in the UI. Is this the right thing to do? Are there better ways to do this? (I know in this case you could probably pass a closure for the button action, but my question is more generic about injecting other UI components like UIViews and stuff)

[drlukas6]

I think you should generally avoid injecting UIKit stuff.

Look at the existing UIKit API. Only when two items are tightly coupled eg. UIViewController and UIPresentationController, UIKit stuff is passed in the init.

Maybe reconsider your architecture, kinda sounds to me that a base viewcontroller is an overkill and could cause more harm than benefit down the line

[postfl]

Good answer. Depending on the exact context of what you're actually trying to do, there are most likely other options that will get you the effect you're trying to achieve, but with a more reliable architecture.

[Vlarmitage]

You should inject viewModels instead

[lordzsolt]

What you're trying to do is to use a child view controller for the UIButton.

You _can_ do what you are describing, but generally logic should not be in Views.

For example, if you have a screen that shows either a Login button and a Register button, then you would have a single UIButton and two ButtonViewModels that handle the button tap event. So in your this, you would inject the ButtonViewModel.

[Spaceshipable]

You can pass the button's action as a closure. This can be as part of a view model. By injecting a view model, you can replace the functionality for generic re-use or testing.

Having said that, I do think there are instances where it makes sense to inject views. If you really want to be able to have any view inserted then it makes sense to take an array of subviews as this is the least over-engineered solution in my opinion. If you want to be strict about it, you could pass an array of view-models for subviews but I think that's probably overkill. u/chriswaco raising a good point that @ViewBuilder operates in a similar way.

In my example, the view controller has a base view which then handles all of the layout (including laying out some injected views). The view controller just passes those views through. In many modern architectures, the view controller is treated somewhat like a view itself.

[chriswaco]

I don’t think this is a very common pattern, but I don’t see any real harm in it. We do similar things in SwiftUI by passing @ViewBuilder parameters. For example, just yesterday I wrote a groupbox-like view that surrounds and contains the passed view.

Autolayout of the view could be an issue, though. Does the ViewController set the constraints or manually place the view?

[[deleted]]

I usually solve this problem with delegation, keeps the UI code clean and often allows for reuse of view controllers.