Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.89%. Comparing base (345ec7c) to head (5df4023).
Report is 13 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #8385      +/-   ##
==========================================
+ Coverage   88.82%   88.89%   +0.06%     
==========================================
  Files         407      407              
  Lines       12226    12226              
  Branches     2441     2441              
==========================================
+ Hits        10860    10868       +8     
+ Misses        834      829       -5     
+ Partials      532      529       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

For future, it's really bad to call JS like this #7155
You will get exception during static / pre-rendering.
For example, when you instantiate a component for first time, the first thing that will fire is SetParametersAsync, but the browser is not yet attached therefore JS runtime is not available. It will only be available after OnAfterRenderAsync.
Dispose can as well fire before the OnAfterRenderAsync in certain scenarios.
For this case we have IsJSRuntimeAvailable property that you need to check every-time you do a call outside of OnAfterRenderAsync like in the Dispose method or SetParametersAsync

For future, it's really bad to call JS like this #7155 You will get exception during static / pre-rendering. For example, when you instantiate a component for first time, the first thing that will fire is SetParametersAsync, but the browser is not yet attached therefore JS runtime is not available. It will only be available after OnAfterRenderAsync. Dispose can as well fire before the OnAfterRenderAsync in certain scenarios. For this case we have IsJSRuntimeAvailable property that you need to check every-time you do a call outside of OnAfterRenderAsync like in the Dispose method or SetParametersAsync

Interesting, I'll take care of that, thanks!

I guess it's too late for me, but what is the difference of this

if (!oldAutoGrow && AutoGrow)
{
	_shouldInitAutoGrow = true;
}
else if (oldAutoGrow && !AutoGrow)
{
	_shouldInitAutoGrow = false;
	await JsRuntime.InvokeVoidAsyncWithErrorHandling("mudInputAutoGrow.destroy", ElementReference);
}

if (firstRender || _shouldInitAutoGrow)
{
	_shouldInitAutoGrow = false;
	await JsRuntime.InvokeVoidAsyncWithErrorHandling("mudInputAutoGrow.initAutoGrow", ElementReference, MaxLines);
	_oldText = _internalText;
}

Compared to what it was without the _shouldInitAutoGrow
and checking AutoGrow && firstRender?
To not call it multiple times?

I'm asking because we'd be able to use ParameterState, but this lines
(!oldAutoGrow && AutoGrow) and (oldAutoGrow && !AutoGrow) makes it harder, since for now we only know that the parameter changed and it's current value, but not the previous value.
@henon what do you think

@ScarletKuro firstRender isn't enough because it also needs to update when the parameter changes so you can perform bindings. but if it hasn't been rendered yet it needs to defer to the firstRender.

enables this:

I'm asking because we'd be able to use ParameterState, but this lines (!oldAutoGrow && AutoGrow) and (oldAutoGrow && !AutoGrow) makes it harder, since for now we only know that the parameter changed and it's current value, but not the previous value. @henon what do you think

We have found a use-case for the oldValue/newValue event args sooner than I'd have expected. Good that the ParameterState framework supports them now!

Thanks Daniel