Sp-dev-docs: Can't display custom dialog more than once

[camstevenson]

Category

• [ ] Question
• [ ] Typo
• [x ] Bug
• [ ] Additional article idea

Expected or Desired Behavior

In the example provided in "Use custom dialog boxes with SharePoint Framework Extensions" (dev/spfx/extensions/guidance/using-custom-dialogs-with-spfx), I expect to be able to invoke the custom dialog more than once.

Observed Behavior

In fact, while the custom dialog renders properly the first time, subsequent invocations result in only the gray overlay being displayed, and no content in the dialog (so a size of 0 x 0 pixels).

This is a result of the the React.render of subsequent invocations trying to be smart about what to render based on what's already been rendered, and ending up rendering nothing.

In the example "ColorPickerDialog", the following method is required:

public async onAfterClose(): Promise {
ReactDOM.unmountComponentAtNode(this.domElement);
}

Steps to Reproduce

Create project using sample code, attempt to invoke "Command 1" multiple times.

[jansenbe]

Duplicate of #2988

[johnguy0]

@camstevenson Thanks for filing this issue.

You can work around this right now by overriding the onAfterClose method with the following snippet:

// In the derived class
protected onAfterClose(): void {
  super.onAfterClose();
  ReactDOM.unmountComponentAtNode(this.domElement);
}

[patmill]

Hey @camstevenson / @jansenbe - quick question on this. Did you update your solution to use React16 to see this, or did you continue to use React15 and this started happening?

[camstevenson]

@patmill I'm using React 16
@johnguy0 Thanks ;-)

[patmill]

Thanks Cam. Trying to figure out if this is simply an issue with the documentation, and with React 16 being more strict, needs to be updated, or if this is something that can/should be fixed in the framework. I'm a bit hesitant fixing things in the framework that should be handled in custom code, but want to make things as simple as possible at the same time.

[camstevenson]

@patmill My opinion and that of my co-workers is that it's entirely logical to unmount the component, and therefore I (we) considered it a documentation issue.

The documentation for React.render does state:

If the React element was previously rendered into container, this will perform an update on it and only mutate the DOM as necessary to reflect the latest React element.

I don't know what's going on underneath the covers in React well enough to say why it would mutate the DOM to nothing.

I guess the only question I would raise is: why is the container element (referenced by this.domElement) hanging around after the BaseDialog derived component is closed? Perhaps that's the root of the problem. Just offering a thought.

Cheers,

Cam

[patmill]

OK. We've created pull requests to explicitly call this out in the documentation. I'm going to close this one down now.

[heinrich-ulbricht]

Quick note: we ran into this issue right after upgrading a solution from SPFx 1.4 to SPFx 1.7.1 (which uses React 16).

[muthugp]

Quick note: we ran into this issue right after upgrading a solution from SPFx 1.4 to SPFx 1.7.1 (which uses React 16).

Me too having same issue with IE

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues