[suggestion]: Conditionals made first-class citizens as part of the StringStylizer DSL

[salguodnz]

Hey Kazuhiro,

I'm not sure if you would want to support this kind of use-case, but consider the following.

Here is a bunch of some of the more convoluted string formation we have.

  let descAttrStrBuilder = promotion.dealDescription.stylize()
            .color(.normalContentTitle())
            .font(.preferredFont(forTextStyle: .subheadline))
        
        if promotion.isPromotionActionable {
            descAttrStrBuilder.underline(.single)
        }
        
        let descAttrStr = descAttrStrBuilder.attr
        
        var validUntil: String?
        if let endsDate = promotion.offerEndsDate {
            let endsDateString = DateFormatter.localizedString(from: endsDate, dateStyle: .short, timeStyle: .none)
            validUntil = "\nOffer Ends: \(endsDateString)"
        }
        
        let endDateAttrStr = validUntil.stylize()
            .color(.normalContentSubTitle())
            .font(.preferredFont(forTextStyle: .footnote))
            .attr
        
        titleLabel.attributedText = descAttrStr + endDateAttrStr

for the promotion.isPromotionActionable block - I wonder if this is something that could be made a 'first class' citizen of the current StringStylizer DSL.

What I mean by this is, It would be cool to write that if block 'in-line' like one of the below two syntaxes.

descAttrStrBuilder.conditionally(promotion.isPromotionActionable).underline(.single)

OR

descAttrStrBuilder.underline(.single, conditionally: promotion.isPromotionActionable)

Option 1 - would mean adding more state into StringStylizer - when a conditionally() is used, you would need to evaluate that in the next 'style code' call (i.e. underline()) and then reset it.
The only issue I have with this is if there is more than 1 'style code' method called. i.e. stylizer.conditionally(true).underline(.single).color(black)
Does the conditional apply to both underline() and color()?
That question is something that this syntax couldn't really communicate unless you were to change conditionally to conditionallySingle() and conditionallyAll() or something like this. It still isn't necessarily natural to consume though.

Option 2 - would be probably easier to understand as a framework consumer - and perhaps could be optional and default to nil or true :). It is not quite as pretty looking as option 1 however.

Either way would involve a pretty decent rewrite. I would be happy to help out if you like such a suggestion.
Or alternatively, of course, you could suggest a better way to write the above snippet 😬