Normalize Slack form element presentational data | Attempt 2

[omotnyk]

Same as #256 but fixed stackoverflow error during normalization caused by cyclic constructor calls in with methods.

[omotnyk]

Replaced with calls with builder here.

[omotnyk]

Replaced with calls with builder here.

[omotnyk]

Replaced with calls with builder here.

[omotnyk]

I'll describe the stack overflow problem with an example. Let's say we have the old code here:

    if (shouldNormalizePlaceholder(element)
        || shouldNormalizeLabel(element, SlackDialogFormElementLengthLimits.MAX_LABEL_LENGTH)
        || shouldNormalize(element.getHint(), SlackDialogFormElementLengthLimits.MAX_HINT_LENGTH)) {
      return SlackFormTextElement.copyOf(element)
          .withPlaceholder(normalizePlaceholder(element))
          .withLabel(normalizeLabel(element))
          .withHint(normalizeHint(element));
    }
    return element;

What we do here is define whether we should normalize any data first and then normalize it. The problem is actually obvious but still tricky. Let's say we have a very long label that should be normalized. In this case, when SlackFormSelectElement is created we do next:

1. Check if we should normalize any field.
2. Determine that we should normalize some fields(label).
3. Start normalization process:
   1. Normalize placeholer and then call withPlaceholder.
   2. Normalize label and then call withLabel.
   3. Normalize the rest.
   4. Build the final normalized object.

The flow I described above is what I think is happening. What was actually happening is we were entering an endless loop upon calling withPlaceholder because unlike builder, this method creates the actual SlackFormSelectElement so it calls method annotated with @Value.Check, which then initiates the normalization process once again. SInce we didn't normalize the label yet, we determine that label still has to be normalized and run SlackFormTextElement.copyOf(element).withPlaceholder(normalizePlaceholder(element)).withLabel(normalizeLabel(element)) once again, which results in doing this again, and then again, and again.

This issue wasn't caught at first because it depends on the order of the checks and normalization as well as on the data to be normalized. If we place withLabel before withPlaceholder and try to build the object with a long label, everything works fine because on the call to withLabel method we have a fully normalized object that passes all the checks.

[zmarushchak-hs]

LGTM!