feat: support multiline for EditableText

[gabriel-amram]

This PR introduces the ability to support multiline in EditableText
if multiline is passed it will render a "textarea" instead of an input that cannot be resized by the user, and instead will grow/shrink according to its content up to a certain max-width or max-height defined by the container.

When using Shift+Enter a new line will be added. Hitting Enter will defocus and change the value

This is useful for users who might want to have a long description and would like to be able to edit it and change the content with line breaks.

When multiline is used, ellipsis is removed from the "view" block and from the "textarea".

• I have read the Contribution Guide for this project.

[talkor]

Thank you for the contribution! Great addition
Please see my comments :)

[talkor]

Just one thought, looks like the only difference in the dimensions is 2px, and there's no difference in paddings/line heights etc between the different variants, so looks like doing just:
setInputHeight(textarea.scrollHeight + 2); works exactly the same and it can save the getComputeStyle and the other calculations in calculateTextareaHeightAttrs (which already have some default static numbers). Giving it auto in the beginning will already make it take the the currect box size. WDYT?

[gabriel-amram]

actually the question gets back to you :)
technically its only 2px because the border-top/bottom-width is 1px (or 2px overall)
border-box should have included the border as well as the padding, but it doesn't

do we want to just rely on always having this border/padding setting and that the user cannot add anything on their own using overwriting css?
@talkor

[talkor]

Well it is border-box, it's just that scrollHeight is based purely on the content and padding of the element's scrollable content, without the borders.
We don't want users to override CSS as it can make design inconsistent so I wouldn't take it into consideration, generally speaking we support the variants we officially provide so it's ok :)
@gabriel-amram

[talkor]

Looks great @gabriel-amram ! Only one thought which I commented, and I did some quick QA and found two things worth checking:

• When focused on the textarea and clicking outside in the same block it will not blur
• When going into edit mode the cursor will be in the beginning of the text instead of the last character which I think makes the experience better

[talkor]

• When focused on the textarea and clicking outside in the same block it will not blur

I mean when clicking on the purple area. I think it's because the 400px width, probably changing it to max-width instead will fix it

[gabriel-amram]

Looks great @gabriel-amram ! Only one thought which I commented, and I did some quick QA and found two things worth checking:

• When focused on the textarea and clicking outside in the same block it will not blur
• When going into edit mode the cursor will be in the beginning of the text instead of the last character which I think makes the experience better

@talkor
the first one, is just a story thing, i removed the wrapping div so its clearer and it works
the second one, this is the default behaviour of browsers (input on focus goes to end of text, textarea to start). i added a piece of code on focus that makes sure that we always go to end of text for both
(this might feel broken though if people are more used to one rather than the other)

[talkor]

Thank you!
IMO worth simplifying the height calculation nevertheless