Which event for notifyOutputChanged

[DianaBirkelbach]

When we have a Textarea PCF control, we can call notifyOutputChanged on the events: "input" or "change" . What's the best practice for that?

If we choose "input", the control will trigger it's own updateView() for every character we type; it doesn't seem to be a good way.

If we choose "change", it will call the notifyOutputChanged only if the textarea looses focus, but when the autosave is triggered before the user leaves the input, the updateView() will be triggered with a old value, and he looses the text he typed.

[ben-thompson]

I've just checked what I do in one of the textarea controls I have and it's called on mouse leave.

It's probably worth saying that we don't use a textarea input control, instead we use an editable div which we set to contentEditable=true onMouseEnter and to false when onMouseLeave at which point we also call notifyOutputChanged

[DianaBirkelbach]

Thank you @ben-thompson for the fast answer.

But if I understand right, you must have the same problem.

To reproduce it, edit another field on the form, just to get the form dirty, then start to edit in your div, and don't leave the div, just wait for the autosave. Then the content edited will be deleted, because the updateView() is called with the old value.

In updateView we have to change the value of the input, because somebody else might have changed the value using the from sdk (outside the control, using attribute.setValue()), so we have to reflect this change.

A workarround would be to check in updateView() to see if the value that we get is different than the last values that we set in getOutputs(), but that's not really right, since somebody might really want to change the value back, using the attribute.setValue().

So it seems to me that we are forced to report every change instantly by calling notifyOutputChanged, which will call again the updateView() method. 

I'm not sure if I can explain what happens. I'll attach a short video about this issue. 

[ben-thompson]

In which case I can't help

I'm using a recentish environment (created this month but not upgraded to wave 1) and autosave is enabled but I can't reproduce the issue as the autosave functionality doesn't seem to be working.  Granted the form does contain 4 different PCF controls but I don't think any of those are the issue. 

Now I would be concerned by that but in April the save button appears so the interface is better.

[ben-thompson]

Scrap that I left it open for 5 minutes and it did autosave without losing data - so I wonder if the issue is that you are using a textarea which is an input field and we use editable Divs with the value stored in the background in a javascript variable.

Looking at the updateview routine we have - we store the raw parameter value in a separate variable and check it every time the routine is called - if the value changes we update the text within the Div otherwise we leave it as is.

[DianaBirkelbach]

Thanks @ben-thompson ! It's a awesome community here! 

Lucky you that it works! 😉 

But then you implemented already one of the workarrounds: you check if the value is a new one, and if it's the value that you already knew, you ignore that: so you ignore the refresh after the autosave.

That would work in most of the cases, but there could happen that the form scripting is calling attribute.setValue(oldValue) in the meanwhile. You would ignore that, right? I agree that won't happen a lot (maybe never), but maybe a plugin sets the value back, and you'll ignore it.  🤔 

In case it helps somebody else, I have now an implementation using an "input" event (to save internal the value), and there I debounce the "notifyOutputChanged" (so it will trigger only once in 250 ms). 

Seems that both solutions are workarrounds. 

[ben-thompson]

To be honest my viewpoint is that autosave is more trouble than it's worth - come April I will be doing everything I can to disable it..

What I care about is that the user interface works the way users would expect it to which means that the form should be displaying exactly what the user expects. So the only time we would update a field within the PCF control is if another control on the form triggered. 

For a lot of our cases that's easy as we are using PCF controls to avoid on page scripting - say field 2 is an (attribute list) attached to field 1 (entity list) so when field 1 changes we reset field 2 and update the options to reflect that change but outside of that you really should be ignoring any value changes - the logic really should be set value on first pass of updateview and ignore that part of the code on subsequent runs. 

[DianaBirkelbach]

Thanks again @ben-thompson . You're right. Actually registering on "input" doesn't work as I thought, since between the autosave start and the moment the form is refreshed, there are a few milliseconds, while the user is typing, so he would lose some chars.

I'll use the workarround  you suggested:  I register on "change" of the input, and in updateView() I ignore the value if it's the old one. So using this workarround the value is not lost after autosave, but it's still not saved until the user change the focus outside the control. So if another script on the form is navigating away or closing the window, the user loses the introduced text.
But I've checked: an out-of-the-box control doesn't their values, they automatically save it somehow. Since I have no influence on the other scripts in the form, I have to be sure that I don't lose the introduced data .

I've made a test by defining in the console the following function (it only saves the form if necessary, and closes the form). I try to simulate another scripts running on the form:

function checkSavingOnLeave(fieldName){
 const value = Xrm.Page.getAttribute(fieldName).getValue();
 console.log(`value at start: ${value}`);
 window.setTimeout( async () => {
    console.log(Xrm.Page.getAttribute(fieldName).getValue());
    console.log(`dirty: ${Xrm.Page.data.getIsDirty()}`);
    const saved = !Xrm.Page.data.getIsDirty() || await Xrm.Page.data.save();
    if(saved===true) {
      console.log(`value before close: ${Xrm.Page.getAttribute(fieldName).getValue()}`);
      Xrm.Page.ui.close();
    }
    else
       console.log("not saved");
 }, 7000);
}

 So I call the function for my pcf control (while the form is not dirty) then I go to my PCF control and I change the text, but don't leave the control for a few seconds, until my script is triggered.

I get this console output:

checkSavingOnLeave("orb_textarea")
value at start: PCF
PCF
dirty: false
value before close: PCF

The form didn't get the change, it gets closed, but the text I typed is lost.

If I call the same function for a standard input control (like the name control) I get the same log

checkSavingOnLeave("orb_name")
value at start: PCF
PCF
dirty: false
value before close: PCF

The difference is that the orb_name (which is a standard control) doesn't loose the changed text, even if the value after the Xrm.Page.data.save() is still the old one, while my PCF control loses the changed text.

Here is my updateView(), in case I do something wrong:

	public updateView(context: ComponentFramework.Context<IInputs>): void
	{						
		const maybeNewValue = context.parameters.myTextarea.raw || "";		
		if(maybeNewValue!== this.value){
			this._inputWindowElement.value = maybeNewValue;	
			this.value = maybeNewValue;			
			console.log(`value set to ${maybeNewValue}`);
		}
		this._inputWindowElement.disabled = context.mode.isControlDisabled;		
	}

This is not a problem related only to textarea, it happens also with a text input.
It's a very simple example of PCF control: just an input control, nothing fancy. Since the standard controls are made using the same framework, Microsoft must have a solution for that already. Maybe somebody from the team can help me...

[HemantG]

Thanks for the inputs and great discussion on this.

I reached out to the engineering team and we have some investigations done. We are evaluating whats the best way to handle this from UCI and form/PCF infra perspective.

One item which we are looking into is to NOT call update on the control via auto-save if the value for that control has not change (tracked by internal bug id 1739331).  Will keep this thread posted on updates.

Hemant Gaur

[DianaBirkelbach]

Thank you very much to all who are helping us. Is a great community.

 @HemantG  Yes, would be great to have this solution: not to call updateView after auto-save.

I just tried my PCF control in a CanvasApp, and the solution that I thought it worked in Model-Driven apps (use the onInput event, so basically only when the user leaves the input) doesn't work in CanvasApps. There we have to implement a Patch requests (since it cannot be integrated in the EditForm-Submit process), and the moment the user clicks the Save Button, the "input" event was not  triggered already (if the user goes directly from the input to the save button), and he loses the data.

So the solution you and the engineers figured out, might be the only way if we want the control to work both in model-driven and canvas apps.

Best regards,

Diana