Setting `errorMessage` on Input/Textarea results in component height change

[tomaszlukasik]

A little related to this issue #1761

I noticed that an Inputand Textarea produce different structures depending on errorMessage presence. This results in height change of the entire component and makes the form view "jumpy". I suppose sometimes just a simple input without an error is needed, but it would be nice to be able to somehow mark that it should nicely support error message.

2 options come to my mind:

1. add some boolean prop indicating that an error message might be present and if true always render an additional div that takes up space
2. remove eventMessage from the Input and Textarea and prepare a wrapper component

https://user-images.githubusercontent.com/1143912/157235513-1ef260eb-3bc4-4a91-b8a9-b59bd86003d2.mov

Additionally, AFAIR we should avoid changing the produced elements tree if possible.

[coderitual]

hey @tomaszlukasik , option 2 can be already implemented on the client side in the app. I believe that the main frontend app is already using custom wrapper. Those kind of wrappers (form fields as they might be called) would be a good candidates to the style guide in my opinion.

Regarding option 1 this is not as simple as adding flag. The problem need to be resolved by designers first because leaving too big gap will cause issues on smaller screen devices and might be seen as an inconsistency compared to other spacing.Also if error text will be too small you decrease legibility/accessibility.

Issue with jumping content might be bigger and smaller depending on the case:

• if the whole form is processed at the and it's not that big issue.
• if you validate particular input in real time (e.g on blur) this might be a slightly bigger problem.

There is always a trade-off between occupying too much space and not causing jumps. I believe it's resolvable (one example might be material ui, but there are plenty other similar solutions) but it's not as trivial as proposed solutions. It's not an implementation bug but something which needs to be resolved on design level in systematic way (with cooperation with designers from product teams)

Additionally, AFAIR we should avoid changing the produced elements tree if possible.

Honestly I don't agree with this statement as a rule. Could you please clarify?