In D5220#153981, @atul wrote:

Hm, at a high level is it the right abstraction to have errorMessage in SubmitButton but displayed "outside" of the button? Maybe we could borrow what we have on landing for the SubscriptionForm component and display the error within the button:

Maybe in a separate/subsequent diff?

---

Either way, accepting to unblock and adding @tomek as blocking

It makes some sense, but this design has some flaws:

• When we display an error message instead of call to action, the purpose of the button might become confusing for the user, especially when retry is a possible action
• When validation fails there might be a couple of reasons and displaying all of them on the button doesn't make sense

These two aren't unavoidable, so with proper message and validation result it could be quite good.

The main reason I would like to avoid doing this here or as a followup is that it breaks consistency with other parts of the app. Also, we should focus on delivering business value instead of spending too much effort on minor improvements. So in this case, we can create a task, assign it a priority (probably low) and implement it when appropriate. Adding unrelated work to a scope of a task is one of the reasons we're not able to estimate things.

Hm, at a high level is it the right abstraction to have errorMessage in SubmitButton but displayed "outside" of the button?

We can call it SubmitSection I guess.