如何在没有固定宽度的情况下将文本包装在 UILabel 中（通过 UIViewRepresentable）？

Question

Setting lineBreakMode to byWordWrapping and set numberOfLines to 0 does not seem to be sufficient:

struct MyTextView: UIViewRepresentable {
    func makeUIView(context: Context) -> UILabel {
        let label = UILabel()
        label.lineBreakMode = .byWordWrapping
        label.numberOfLines = 0
        label.text = "Here's a lot of text for you to display. It won't fit on the screen."
        return label
    }

    func updateUIView(_ view: UILabel, context: Context) {
    }
}

struct MyTextView_Previews: PreviewProvider {
    static var previews: some View {
        MyTextView()
            .previewLayout(.fixed(width: 300, height: 200))
    }
}

The text does not wrap, regardless of which setting I use for lineBreakMode. The canvas preview and live preview both look like this:

The closest I've gotten is setting preferredMaxLayoutWidth, which does cause the text to wrap, but there doesn't seem to be a value that means "whatever size the View is".

Answer 1

Possible solution is to declare the width as a variable on MyTextView:

struct MyTextView: UIViewRepresentable {

    var width: CGFloat

    func makeUIView(context: Context) -> UILabel {
        let label = UILabel()
        label.lineBreakMode = .byWordWrapping
        label.numberOfLines = 0
        label.preferredMaxLayoutWidth = width
        label.text = "Here's a lot of text for you to display. It won't fit on the screen."
        return label
    }

    func updateUIView(_ view: UILabel, context: Context) {
    }
}

and then use GeometryReader to findout how much space there is avaible and pass it into the intializer:

struct ExampleView: View {

    var body: some View {
        GeometryReader { geometry in
            MyTextView(width: geometry.size.width)
        }
    }
}

Answer 2

Try to use this magic line in makeUIView() func

label.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)

Answer 3

I found a somehow "nasty" approach that allows a UILabel to properly wrap when used as a UIViewRepresentable ( even when inside a ScrollView ), without the need for GeometryReader :

Whenever creating your UILabel :

label.setContentCompressionResistancePriority(.defaultLow,
                                              for: .horizontal)
label.setContentHuggingPriority(.defaultHigh,
                                for: .vertical)

This ensures that:

• the label will break line and not have an infinite width
• the label will not add grow unnecessarily in height, which may happen in some circumstances.

Then...

• Add a width property to your UIViewRepresentable that will be used to set the preferredMaxLayoutWidth
• Use your UIViewRepresentable into a vanilla SwiftUI.View
• Add a GeometryReader as an overlay to prevent expansion
• Trigger the measurement after a soft delay, modifying some state to trigger a new pass.

ie:

    public var body: some View {
        MyRepresentable(width: $width,
                        separator: separator,
                        content: fragments)
            .overlay(geometryOverlay)
            .onAppear { self.shouldReadGeometry = true }
    }

    // MARK: - Private Props

    @State private var width: CGFloat?
    @State private var shouldReadGeometry = false

    var geometryOverlay: some View {
        if shouldReadGeometry {
            return GeometryReader { g in
                SwiftUI.Color.clear.onAppear {
                    self.width = g.size.width
                }
            }.eraseToAnyView()
        } else {
            return EmptyView().eraseToAnyView()
        }
    }

OLD ANSWER:

...

In your updateUIView(_:context:) :

if let sv = uiView.superview, sv.bounds.width != 0 {
    let shouldReloadState = uiView.preferredMaxLayoutWidth != sv.bounds.width
    uiView.preferredMaxLayoutWidth = sv.bounds.width
    if shouldReloadState {
        DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + 0.1) {
            self.stateToggle.toggle() // a Bool @State you can add in your struct
        }
    }
}

Disclaimer: I'm not a huge fan of main.async calls, particularly when they come in combination with some arbitrary delay, but this seems to get the work done in a consistent way.