Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add preventClose #9

Open
janwirth opened this issue Mar 22, 2022 · 3 comments
Open

Add preventClose #9

janwirth opened this issue Mar 22, 2022 · 3 comments

Comments

@janwirth
Copy link

class PreventClose extends HTMLElement {
  // set up events
  connectedCallback() {
    // disable on localhost for david's sanity
    if (window.location.host.includes("localhost")) {
      return;
    }
    this.beforeUnloadListener = (event) => {
      event.preventDefault();
      return (event.returnValue =
        "Are you sure you want to exit? There are unsaved changes.");
    };
    addEventListener("beforeunload", this.beforeUnloadListener, {
      capture: true,
    });
  }
  disconnectedCallback() {
    removeEventListener("beforeunload", this.beforeUnloadListener, {
      capture: true,
    });
  }
}

customElements.define("prevent-close", PreventClose);
@timcase
Copy link

timcase commented Mar 22, 2022

This looks like an example of something that should not be done as a Custom Element because it's not actually extending HTMLElement. The web component is being used as a convenience for adding arbitrary javascript via the DOM, it's being added to the DOM, but it doesn't actually have any reason to be in the DOM.

Why not use a port instead?

How web components was originally envisioned was as leaf-node or light-DOM-using components

@janwirth
Copy link
Author

janwirth commented Mar 26, 2022

Following arguments for declaring this behavior in the DOM:

  • head tags are in the DOM, we can control the title from the view. The line here is blurry
  • using the port and tracking the state of the outside world requires a lot of glue code and data massaging if you have a big view
  • the knowledge about what needs to be saved before losing it is often available in the view "You have unsaved changes, click here to save". So why not declare the behavior there?

image

@mfeineis
Copy link
Collaborator

Personally, I like the idea to enable the view to prevent closing the window without the ceremony. What about we put this example somewhere here with a caveat mentioning that it's not exactly a "pure" way to do it?

My deal with Evan at the time was that outside of maintenance the /more directory is my domain, so right now I'm thinking of a separate document maybe sth. like "Gray Patterns" where we can have a nice disclaimer on top of the document and have a place to put useful custom elements like your PreventClose. @janwirth what do you think about that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants