[TextareaAutosize] Convert code to TypeScript

[sai6855]

closes: #34721

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

https://deploy-preview-35862--material-ui.netlify.app/

Bundle size report

Details of bundle changes

Generated by 🚫 dangerJS against b734b86

[sai6855]

'rootClass' is not present in fullSuite, hence removed to make typescript happy.

material-ui/test/utils/describeConformanceUnstyled.tsx

Lines 321 to 332 in f13e534

	const fullSuite = {
	componentProp: testComponentProp,
	slotsProp: testSlotsProp,
	slotPropsProp: testSlotPropsProp,
	slotPropsCallbacks: testSlotPropsCallbacks,
	mergeClassName: testClassName,
	propsSpread: testPropForwarding,
	reactTestRenderer: testReactTestRenderer,
	refForwarding: describeRef,
	ownerStatePropagation: testOwnerStatePropagation,
	};

[sai6855]

height and overflow values are changed from empty strings to '0px' and 'hidden' because previously getComputedStyleStub was using object and setLayout is mutating this object in below line and setting styles to {height:"",overflow:""}, this is not expected. now since Map is being used in place of object we came to know about this bug.

Just for reference i'm attaching codesandbox demo https://codesandbox.io/s/stoic-darkness-t1jp9o?file=/demo.js , which renders just TextAreaAutoSize, On inspecting textarea[aria-hidden=true],textarea[aria-hidden=null] elements , you can see height and overflow are indeed '0px' and 'hidden'.

cc @michaldudak

[michaldudak]

The KebabKeys type looks pretty clever, but I wonder if we can not use it at all (it's a recursive inferred conditional type - the type checker would be happy we save it from doing this work 😉). The CSSStyleDeclaration type is defined with camelCase keys and works fine this way. We should be able to simplify the implementation by changing the getStyleValue to:

function getStyleValue(value: string) {
  return parseInt(value, 10) || 0;
}

and call it with just getStyleValue(computedStyle.paddingBottom) instead of using [] for property access.

Unless there's a good reason why the current implementation looks as it does (cc @oliviertassinari).

[oliviertassinari]

and call it with just getStyleValue(computedStyle.paddingBottom) instead of using [] for property access. Unless there's a good reason why the current implementation looks as it does (cc @oliviertassinari).

Nothing that I recall. Looking at our codebase, we like to do it in all the possible ways 😅. I can find:

• computedStyle.getPropertyValue('transform')
• const firstChildMarginLeft = parseToNumber(firstChildComputedStyle.marginLeft);
• getStyleValue(computedStyle, 'padding-bottom')

They behave almost identically:

• https://stackoverflow.com/questions/56586320/is-there-a-difference-between-getpropertyvalue-and-the-bracket-notation-for
• https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle
  

[oliviertassinari]

I would be in favor of removing all the defensive checks. e.g. this one and if (inputRef.current) {. As far as I know, these are guaranteed to be defined even if TypeScript doesn't know it. We would ship less code.

[michaldudak]

👍 We haven't seen any bug reports related to not having these checks in the JS version, so it's safe to skip them here as well.

@sai6855 would you mind correcting this? The rest of the PR looks fine to me.

[sai6855]

done, removed defensive checks , commit: cb83064 . cc @michaldudak

[sai6855]

removed kebabtypes as per #35862 (comment), but hold on to (#35862 (comment)) change

[michaldudak]

Could you please merge in the latest master? This should help with the Argos CI check.

[sai6855]

@michaldudak done, merged lastest master

[michaldudak]

All right! Everything seems to be in order.
Thanks for your work on this!