FeatureFormView & PopupView - Add ._Title(_:)

[dfeinzimer]

Closes #835

Adds modifiers to PopupView and FeatureFormView allowing developers to hide the titles.

[dfeinzimer]

Changing this to internal allows FeatureFormView to access the default value.

[dfeinzimer]

This needed to change to -> FeatureFormView so that the two FeatureFormView modifiers can be placed in any order.

[dfeinzimer]

I'm not set on this modifier for one reason - the showCloseButton button modifier.

It seems disjoint that a developer can hide the title and simultaneously leave the close button visible.

PopupView(popup: popup!, isPresented: $showPopup)
    .popupTitle(.hidden)
    .showCloseButton(true)

Should we instead deprecate showCloseButton and add something like .popupHeader(_:) which would hide both?

[mhdostal]

The title and close button are not necessarily related, other than they have been occupying the same space. It may be that the client doesn't want the title in the popup/view but still requires the close button. So I'm OK having them both be distinct and put the onus on the client to figure out how they want it to display/behave.

[rolson]

I agree with David that it is a bit disjoint. I'm not sure we should've had a simple boolean for the close button. Some people might prefer a "Done" button. There is no way to customize that (well I guess the library is open source so people could customize it).

The isPresented works if using the toolkit's FloatingPanel. And I guess it works with .sheet as well, but it's actually unnecessary with .sheet because we could have used the DismissAction environment value:

@Environment(\.dismiss) private var dismiss

I think, for the most part, our components should not assume their container.

Since title text is sometimes (often) on the "same line" as some buttons (done, cancel, menu), we might do better with a constructor like this that enables the PopupView to build a header for situations where they want to add a close button, but the title isn't displayed in a navigation toolbar:

struct PopupView<HeaderContent: View>: View {
    let popup: Popup
    let headerContent: ((String) -> HeaderContent)?

    ...
    
    /// Creates a PopupView...
    /// - Parameters:
    ///   - popup: The Popup to display
    ///   - headerContent: A closure that builds the header for a given title
    init(popup: Popup, @ViewBuilder headerContent: @escaping (String) -> HeaderContent) {
        self.popup = popup
        self.headerContent = headerContent
    }

This would allow somebody to add their own title, buttons, etc.

That would solve the close button thing. Then I guess there could be some modifier for header(_ visibility:).

[dfeinzimer]

@mhdostal Any preference on the individual title and close button controls vs. Ryan's suggestion?

[mhdostal]

I'm OK with @rolson 's suggestion. That does solve the issue with the "close" button and allows clients to set it up how they want. It's a good point that our components should not assume their container. We could be better trying different containers to verify that.

[mhdostal]

The title and close button are not necessarily related, other than they have been occupying the same space. It may be that the client doesn't want the title in the popup/view but still requires the close button. So I'm OK having them both be distinct and put the onus on the client to figure out how they want it to display/behave.

[mhdostal]

Why an enum instead of a Bool? shouldShowTitle, or something similar?