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

issue about destroy glcomponent #87

Open
SangJuBaek opened this issue Sep 4, 2020 · 12 comments
Open

issue about destroy glcomponent #87

SangJuBaek opened this issue Sep 4, 2020 · 12 comments

Comments

@SangJuBaek
Copy link

SangJuBaek commented Sep 4, 2020

@eddow

I'm sorry to bother you.

Could you tell me how the error handling of this issue is going?

@eddow
Copy link
Collaborator

eddow commented Sep 8, 2020

Oh - sorry - I guess one has no notifications when the bug is closed.
Well, please describe what you mean by "when I tried to destroy the gl-component" - here, I closed all the closable documents and had no bugs.
Which gl-compenent are you trying to destroy? Did you add code in the demo ? If yes, could you share it ?

@SangJuBaek
Copy link
Author

Oh, I'm sorry. The error in the screen shot is the error that occurs when the demo-stack is closed, not gl-component. My mistake.

Actually, the problem I am currently experiencing occurs when the @destroy callback of gl-component is called.

I saved the data to draw the gl-component inside the stack in the vuex store. And if I closed the gl-component, I tried to remove the data that made up that gl-component from the store through @destory callback. But after the initial normal removal, the @DesToy callback is called back. At this time, an attempt is made to erase another gl-component in the same stack that is not subject to the destroy.

I tried to make a demo through the code sandbox, but errors such as the screenshot attached are occurring. Other vue-golden-layout examples of code sandbox are experiencing the same error. I think I can't deliver an example through this.

sandboxError

Have you ever seen a case like this?

If an example of the current situation is needed, how should it be communicated?

@eddow
Copy link
Collaborator

eddow commented Oct 21, 2020

I really tried several time unsuccessfully to find out the bug or even a case where @destroy is called twice on a component.
A sand-box with the error would definitely greatly help.

@SangJuBaek
Copy link
Author

I tried to provide a sandbox, but I couldn't because there was an error like a screenshot.
goldenlayout
How should I hand over the code to you?

@SangJuBaek
Copy link
Author

I finally figured out which part was the problem.
My source manages data about gl-components in the form of json objects in the vuex store and draws it on the screen via v-for in the template.
If you click the close button of the header, you are riding the flow as follows, as I have roughly identified.

goldenLayout

Within the callback function for 'remove child callback' (Our web), I'm splicing data about the data in the vuex store that should be closed. (red box)
When this is done, it seems that the deletion logic is called again by calling 'destroyed hook' (blue line)

Is there any way I can handle this part?
If this usage is wrong, could you tell me what other methods I should use?

@SangJuBaek
Copy link
Author

The part that calls'remove child callback' is'_$destory(Stack)'.
It is not'remove child(component)'.
I'm sorry. It's my mistake.

@SangJuBaek
Copy link
Author

I corrected the wrong part.

goldenLayout

@hartum
Copy link

hartum commented Jan 26, 2021

I also tried to upload an example to codesandbox and got the same error:
download-1

So if you don't mind, I've prepared a zip file with a super basic example, here
Or if you prefer you can view and download it straightly from github

After running you will see a screen like that:
download-2

Just press the button and see the error in console.

@eddow
Copy link
Collaborator

eddow commented Apr 9, 2021

I finally found the origin of the error.

Indeed, the "destroy stack 2" I don't know why, destroys both the stacks.

It seems that it occurs when the stacks container (here the gl-row) is the root of the layout.
For now, I can only advise you a workaround by putting the gl-row in a gl-col who contains only this element

@ken-xxx
Copy link

ken-xxx commented Jun 11, 2021

@eddow i have the same problem, how do I fix it?

@nsjoo
Copy link

nsjoo commented Jun 21, 2021

@eddow +1
it's still happening.
I would like to know the current status of this issue.

@eddow
Copy link
Collaborator

eddow commented Jul 20, 2021

For now, I can only advise you a workaround by putting the gl-row in a gl-col who contains only this element

The solution is really cost-less - and the problem is too bizarre to make it a priority

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

5 participants