Skip to main content

Bug Tracker

Side navigation

#13400 closed feature (duplicate)

Opened February 06, 2013 11:52AM UTC

Closed March 07, 2014 02:38PM UTC

Last modified June 25, 2014 06:10PM UTC

.replaceWith() with .detach() instead of .remove()

Reported by: anonymous Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: git
Keywords: Cc:
Blocked by: Blocking:

I would like to propose a version of .replaceWith() that doesn't do .remove() but .detach() instead.

The problem is that the .remove() call in .replaceWith() removes all data and events attached to the element. When putting the element back in the DOM at a later time, it is often useful to still have the data/events bound.


Attachments (0)
Change History (10)

Changed February 06, 2013 01:20PM UTC by dmethvin comment:1

resolution: → wontfix
status: newclosed

It's not a case of just leaving data and events "in place" on the old element. Since you're *replacing* the element, the only way to do this would be to copy the data and events from the replaced element.

Since we've gone seven years without anyone requesting this, I think it's rare enough that you should just manage it in the app, either by using delegated events or re-attaching them.

Changed February 28, 2013 01:50PM UTC by anonymous comment:2

Just for the record, I don't think it's that rare...

The need arises for example when implementing a 'wizard-like' navigation. You need to replace the contents of a node each time 'next' is clicked, but when 'back' is clicked you still want the original contents with their event handlers in place.

Changed August 30, 2013 06:25PM UTC by comment:3

Just came across this issue, because I want to toggle content upon click whereas the toggle "switch" is part of the content. In this case, it would be useful to just replace one element with another without losing attached event handlers.

Changed October 30, 2013 08:39AM UTC by anonymous comment:4

I also just came to this. Navigation using scroll fix headings, when the user scrolls to a point header.replaceWith(placeholder) and fix the heading, but event handlers get lost. Had to do header.before(placeholder).detach(). Not the end of the world I suppose.

Changed January 16, 2014 07:15AM UTC by jameshartig comment:5

I think the last comment meant to say the solution is



It doesn't make sense otherwise.

Changed January 31, 2014 01:49PM UTC by anonymous comment:6

I too came across the requirement to keep events en-tacked using replaceWith. It seems as though this would be a very simple fix, no?


jQuery( this ).remove();
parent.insertBefore( elem, next );

... would become

if ( detach ) {
	jQuery( this ).detach();
	parent.insertBefore( elem, next );

Then there could be two functions. One for detach and another for the normal replaceWith (both of which call the private function using the detach flag that actually does the work).

Changed March 06, 2014 09:03AM UTC by steven_ganz comment:7


See also #14181.

Changed March 07, 2014 02:37PM UTC by dmethvin comment:8

resolution: wontfix
status: closedreopened

Changed March 07, 2014 02:38PM UTC by dmethvin comment:9

resolution: → duplicate
status: reopenedclosed

Duplicate of #14181.See the plugin in #14181. There is no reasonable way to add a boolean argument to .replaceWith() so the best solution is a new API, which given the rare need is best done as a plugin.

Changed June 25, 2014 06:10PM UTC by paulscode comment:10

In case anyone arrives here as I did looking for a quick alternative to replaceWith() that keeps attached events, it can be done using a combination of existing functions in the current API:


    old.replaceWith( new );

can be changed to:

    old.before( new ).detach();

Both return a handle to the removed element, so depending on the use case it should be pretty simple to change.