Skip to content
This repository has been archived by the owner on Jul 29, 2019. It is now read-only.

Network - options object unexpectedly modified by network.setOptions #1660

Open
rjbriody opened this issue Feb 16, 2016 · 5 comments
Open

Network - options object unexpectedly modified by network.setOptions #1660

rjbriody opened this issue Feb 16, 2016 · 5 comments

Comments

@rjbriody
Copy link

Hello.

The options object is being unexpectedly modified to invalid options when calling network.setOptions.

https://jsfiddle.net/4jtopnmj/4/

To reproduce:

  • Double-click a node. This will use a 2nd set of options that specify hierarchical layout.
  • Double click the canvas to switch back to the original options. 2 things go wrong here:
    • The edge smooth is still cubicBezier in the graph, but should be continuous. This is pretty clearly a symptom of the 2nd problem...
    • If you look at the console output then you will see that the smooth config is altered during network.setOptions.
@AlexDM0
Copy link
Contributor

AlexDM0 commented Feb 16, 2016

Hi,

the hierarchical layout is altering the options but it seems the reverting is not done correctly.

Well look into this. Thank you for reporting!

Regards

On 16 Feb 2016, at 01:54, bobb notifications@github.com wrote:

Hello.

The options object is being unexpectedly modified to invalid options when calling network.setOptions.

https://jsfiddle.net/4jtopnmj/4/

To reproduce:

Double-click a node. This will use a 2nd set of options that specify hierarchical layout.
Double click the canvas to switch back to the original options. 2 things go wrong here:
The edge smooth is still cubicBezier in the graph, but should be continuous. Which is pretty clearly a symptom of the 2nd problem...
If you look at the console output then you will see that the smooth config is altered during network.setOptions.

Reply to this email directly or view it on GitHub.

@lftakakura
Copy link

same here

@mojoaxel
Copy link
Member

I'm closing this issue due to inactivity.
If you think this issue is still relevant please feel free to reopen!

@rjbriody
Copy link
Author

This is still relevant. My uninformed opinion is that it seems like vis.js should clone the incoming settings object upon reception so that any intentional or accidental modifications to the settings are not leaked back to the user object being passed in.

@wimrijnders
Copy link
Contributor

I agree, opening it again.

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

No branches or pull requests

5 participants