React-beautiful-dnd: cannot unpublish descriptor when none is published

[seap]

Bug or feature request?

upgraded to 4.0, print the error as below
cannot unpublish descriptor when none is published

could you please explain the issue? thanks in advance.

_this.unpublish = function () {
      if (!_this.publishedDescriptor) {
        console.error('cannot unpublish descriptor when none is published');
        return;
      }

Expected behavior

Actual behavior

Steps to reproduce

Browser version

Demo

[alexreardon]

Hi @seap can you please post an example that reproduces this issue?

Here is a template to start from: https://www.webpackbin.com/bins/-Kr9aE9jnUeWlphY8wsw

[robbinjanssen]

Got this as well (note; im new using this library). But this occurred to mean when I navigate to a page using react-router's <Link /> component (v2), and then use the browser 'back' button.

[alexreardon]

Without a reproducible example it is hard to know what is going on... As long as nothing is changing during a drag you should no see this message

[humphreybc]

We're seeing this with Dovetail. When you open a project, use the browser back button, then open the project again these errors appear. I thought I had an idea for what was causing it but I couldn't create a reproduction case. So now I'm not sure. I don't really have time to investigate further unfortunately. For us it doesn't seem to happen with a low number of draggables; only when you get past the ~100 mark. Here's a gif:

[alexreardon]

This error message occurs when you attempt to unmount a component that has not registered itself with our dimension publisher. This should never happen. Without a reproducible example this is difficult to dive into more deeply.

Boilerplate: https://www.webpackbin.com/bins/-Kr9aE9jnUeWlphY8wsw

[humphreybc]

@alexreardon We're probably doing something wrong on our side. Do you mind giving a little more information to help track this down?

• Are both draggables and droppables registered with the dimension publisher?
• At what point does the registration happen?

[alexreardon]

registration occurs when the component is mounting (as the ref has resolved)
unregistration occurs when the component is unmounted

Somewhere to look: is the component being unmounted extremely quickly? Without having a look around some code that is having the issue it is hard to dig deeper

[czechdave]

I'm experiencing the same issue. It seems to be related to client side navigation as it only happens when I navigate to/from a page with draggable. Maybe react-router is somehow effecting the mount/unmount lifecycles? I'll report back if I find any more details.

[alexreardon]

For now i'll close this until we have new information

[jeanpaulsio]

Hi!

So for what it's worth - I just ran into this error and it was happening when the data that I was iterating over was empty. For example -

When data is empty,

<Droppable droppableId="droppable">
  {(provided, snapshot) => (
    <div ref={provided.innerRef} style={getListStyle(snapshot.isDraggingOver)}>
      {data.map((item, index) => (

      {/*       rest of code        */}

will give me the error:

index.js: cannot unpublish descriptor when none is published

I just threw a guard clause in there to avoid this. Something like:

if (!data.length) return;

[alexreardon]

This warning is caused by changing a list during a drag which is currently not supported. So as long as your list length is not changing you should not see this.

It is caused by unmounting a draggable or droppable component during a drag.

[humphreybc]

This warning is caused by changing a list during a drag

@alexreardon In the gif I posted, there's no drag happening.

[alexreardon]

Strange!! Can you please upgrade to 6.0 and let me know if you still get
the warnings?
On Wed, 14 Mar 2018 at 12:55 pm, Benjamin Humphrey [e-mail]
wrote:

This warning is caused by changing a list during a drag

@alexreardon https://github.com/alexreardon In the gif I posted,
there's no drag happening.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/279#issuecomment-372878459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7eBNRrEPEpOcr-yEbmkzemBVAxGpks5teHiBgaJpZM4RiVSh
.

[humphreybc]

@alexreardon Just upgrade to 6.0.0 to see, and unfortunately the console output is still there:

Also, unrelated to this issue, is there a way to disable the Set window['__react-beautiful-dnd-debug-timings-hook__'] = true to enable timings message in the console? I can open another issue, just thought I'd ask first.

[alexreardon]

I am off the week. I’ll take a look next week. However I will need a stand
alone codesandbox to be able to action this. The debut console warning only
occurs in a dev environment but I think I should turn it off anyway :)
On Wed, 14 Mar 2018 at 7:13 pm, Benjamin Humphrey [e-mail]
wrote:

@alexreardon https://github.com/alexreardon Just upgrade to 6.0.0 to
see, and unfortunately the console output is still there:

[image: unpublish-error]
https://user-images.githubusercontent.com/1124253/37390311-a5b20f3a-27bb-11e8-9b57-f52f394ea1e1.gif

Also, unrelated to this issue, is there a way to disable the Set
window['__react-beautiful-dnd-debug-timings-hook__'] = true to enable
timings message in the console? I can open another issue, just thought
I'd ask first.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/279#issuecomment-372937730,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7YF7R-60mgaAuaGT47kISwvJyoKdks5teNEhgaJpZM4RiVSh
.

[gabrielfurini]

Hey guys, I'm experiencing the same issue here. Both on 5.0 and 6.0 releases.

[hpeikari]

Same issue here !

[bmaximilian]

Same issue here

[12tp12]

same issue

[lukebatchelor]

Hi everyone. Please read the thread above before commenting with +1's.

• This is a standard error, not something specific, what's causing it for one person may not be what's causing it for others
• As mentioned multiple times, if we are going to investigate this, someone needs to reproduce this in a sandbox. The issue is obviously specific to how you are using this tool. If you don't show how you are using it, we can't help you.
• +1 comments achieve absolutely nothing but spamming maintainers. GitHub has reactions for this exact purpose. Please use them.

Thanks!

[alexreardon]

I am looking into this one now

[alexreardon]

But I am still unable to reproduce it...

[alexreardon]

I am looking at the code an I currently cannot explain why the issue is occurring. Can somebody please put together a codesandbox with their failing code?

[humphreybc]

@alexreardon A while back I tried to put together a reproduction since I had a suspicion it was something to do with React Router. I got a codesandbox working but couldn't reproduce this problem. My next hunch is that it might be something to do with data loading asynchronously, and the array of droppables or draggables being empty very briefly during render. The next step is trying to mimic async loading of data in a sandbox, as if it were coming from a server (via Apollo in our case). It would be quite interesting to know the stack from the other people who are having this issue.

[alexreardon]

Thanks @humphreybc. Tracing through the code I cannot seem to find a scenario where this message can be printed. Obviously there is (you found it) but I have no idea what it is. Without an example that reproduces it that I can poke around with it is super hard to get to the bottom of this one

[coffeedoughnuts]

Hi there - i'm also having this issue, and also tried to recreate in a more vanilla environment, but failed.

My stack includes React 16, Redux, React-Router & Apollo. I have data loading via Apollo based on an ID in the URL and the resulting data from the GraphQL query finds it's way into some droppables.

The errors occur when clicking React Router NavLinks to change page (resulting in new data from Apollo). It's worth noting i get multiple errors of this type; it seems like one for each draggable.

I can't post my code publically unfortunately, but will try again to recreate in isolation.

[nodefiend]

also having issue , just upgraded to 6.01 , it seems to be happening as soon as i switch to new view(/route) , i am using "react-router": "3.0.5"

[alexreardon]

I am still unable to reproduce this. However, this issue might go away altogether as a part of our upgrade to React 16 #406 as it is changing how we pass ref's around internally.

I also think the issue might have been caused by an abandoned mount by React 16 which is now accounted for

[chrisjhoughton]

An hour of debugging and I finally got to the bottom of what was causing this for us! Adding my findings here to help everyone out.

Steps to reproduce in our app:

1. Visit a page with DND on
2. Go to another page
3. Go back to the original page, via the back button or a link

The errors only ever showed on the 2nd, 3rd, 4th ... time, but never on the first.

Debugging through the Chrome console and looking through the unpublish() calls - I discovered the issue - we were mounting and unmounting the DragDropContext (and everything beneath it) extremely quickly on the 2nd + time.

This is actually a common pattern (mistake?) when using Redux - we store the "loading state" of a given record that's being loaded in the global store. This meant that the record was already loaded and saved in the store, but as soon as the user navigated to the record we then immediately reloaded it - causing a rapid mount-unmount, before mounting again after loading.

The problem came when the quick unmount happened - it's like the unpublish() call was trying to run before the publish() call was finished.

Cleaning up our Redux store on our main component unmount fixed the issue.

I'm not sure what the approach to solve this more generally is - but I hope my findings + fix are useful!

[alexreardon]

Thanks @chrisjhoughton !

I think the issue is caused by an aborted React 16 mount. As part of our React 16 upgrade #406 we are now using lifecycle methods that are non suseptable to aborted mounts. Additionally we are no longer double rendering components on ref changes which should also eliminate this timing issue.

Closed by #406.

If anyone sees this after 7.0 is released, please feel free to reopen this issue