Fit to window causes the graph to shrink to one node

[ahmad00m]

When fit to window option from the setting is chosen, the graph shrinks down to one node but it appears that reselecting another view size causes the graph to go back to normal.

[dondi]

This one will need some prior reading on the D3 library. The classic starter is the “Three Circles” article. It also appears that D3 has updated its introductory page in the interim

[Sarronnn]

Could not get the graph to show up: do I need to upload a gene sequence?

• Looked at developers tool: Error message showed "Failed to load resource: the server responded with a status of 404 (Not Found)" " DevTools failed to load source-map"

[kdahlquist]

You should be able to reproduce this just by loading the demo files under the demo menu.

[Sarronnn]

I tried the files under demo:

• The graph does not show up on the local GRNsight, but it does on the actual one .

[Sarronnn]

And what is a D3 scale=> A function; calling it returns the visual value (such as an x-position) corresponding to the given abstract value (such as a count). Under graph.js: Am I looking at the correct function? If so:

From Thre Little Circles :

• With a selection, we can make various changes to selected elements. For example, we might change the fill color using [selection.style] and the radius using [selection.attr]
  • circle.style("fill", "steelblue");
  • circle.attr("r", 30);_

Questions:

• _.attr("height", $(".grnsight-container").hasClass(VIEWPORTFIT) ? newHeight : newHeight); : what does this line of code do?
• Still do not understand adaptive?
• viewport class?

[dondi]

@Sarronnn if you have any updates on this since last time, please post when you can, thanks!

[Sarronnn]

Currently: Trying to understand what code is saying. // Subtract 1 from SVG height if we are fitting to window so as to prevent scrollbars from showing up // Is inconsistent, but I'm tired of fighting with it... d3.select("svg").attr("width", newWidth) .attr("height", $(".grnsight-container").hasClass(VIEWPORT_FIT) ? newHeight : newHeight); d3.select("rect").attr("width", width).attr("height", height); d3.select(".boundingBox").attr("width", width).attr("height", height);

Question: Am I looking in the correct place? Searched the key word "fit to window" and this line of code showed up. But I'm not sure if this part of the code deals with fitting the graph to the window because the comment above it says something about scrollbars.

[Sarronnn]

This seems to no longer be an issue. When the "fit to window" setting is selected, the graph shrinks to fit the window, i.e it no longer shrinks to just one node.

[dondi]

Interesting—we can verify this upon the next deployment to beta

[dondi]

Unfortunately, on beta v6.0.3, I was still able to replicate this behavior 😔

[kdahlquist]

@Sarronnn will check to see if this is replicable as part of #1012

[Sarronnn]

• I was not able to replicate this bug on my branch.
• But the bug is replicable on beta v6.0.3.
• Difference between my branch & beta? Here is my version:

Here is beta v6.0.3:

[dondi]

This may need more triage—vary various conditions, log/journal specific sequences of actions (so you know not to repeat yourself)…discrepancy is confirmed by @Onariaginosa

[dondi]

At a minimum, let’s try to document any conditions that either make the bug reliably replicable or reliably not replicable—maybe by having those summarized in writing, we can draw some insight on what is making the difference

[Sarronnn]

On my machine	On Beta
Reload → pick demo → fit to window--- (Bug isn’t replicable)	Reload → pick demo → fit to window--- (Bug is replicable)
Reload → fit to window → pick demo--- (Bug isn’t replicable)	Reload → fit to window → pick demo--- (Bug isn’t replicable)
Reload → pick demo → large view → fit to window--- (Bug isn’t replicable)	Reload → pick demo → large view → fit to window--- (Bug is replicable)
Reload → pick demo → small view → fit to window--- (Bug isn’t replicable)	Reload → pick demo → small view → fit to window--- (Bug is replicable)
Change demos as fit to window is checked--- (Bug isn’t replicable)	Change demos as fit to window is checked--- (The now loaded graph is not shrinking)

• Conclusions => 

• The bug is replicable on beta only. Could not replicate bug on my branch; at least not in the possible checks that I have tried. 

• Looks like if we check “fit to window” first, before loading a demo, then proceed to load demo, the bug is not replicable on beta. 

[kdahlquist]

Hypothesis:

• when we do npm install today, we get a separate set of libraries than have been sitting on the server
• @dondi will download from server so a comparison can be made
• If file isn't too large, zipped, will post to issue, otherwise post on slack
• move current node modules elsewhere and then replace the folder with the downloaded on and see if the bug can then be replicated
• d3 library is a suspect

[kdahlquist]

Could also investigate whether being embedded in the website has an effect.

[dondi]

Total size: 321M, compressed is ~80M

GitHub issues will only accept a 25M maximum, so this has been placed in the Box GRNsight folder: https://lmu.app.box.com/folder/100940731183 (_node_modulesbeta.zip)

@Sarronnn ☝🏽 (or anyone else who is interested in trying, for that matter)

[Sarronnn]

• Downloaded zip file of beta's node module -Moved current node modules elsewhere and then replaced the folder with the downloaded one.
• Could not do npm run start-dev

• Another issue I ran into: When trying to "Load from database", the network source has a default selection of "undefined: 2022-09-24"; and I can't seem to change this.
• I deleted package lock and change the pg in the package.json file to 8.0.3; but the issue still persists.
• Node version is 14.21.2

[kdahlquist]

To clear the undefined bug, pull from @Onariaginosa 's branch.

@Sarronnn and @dondi will meet to work on the npm run start-dev issue in office hours.

[Sarronnn]

Possible reasons branch is not replicable: 1) Configuration differences: My branch may have a different configuration or environment setup compared to the main branch, which may affect the behavior of the application.

• To test this, I made sure I pulled and was up to date with Master.
• I still was not able to replicate the bug when I switched back to my branch

2) Dependencies: My branch may have different dependencies compared to the main branch, which could affect the behavior of the application. For example, if a library or module used in my branch is different from the one used in the main branch, this could cause the issue to occur or not occur.

• Check to see if there are any dependency differences between your branch and main.
• D3 modules?
• Found error: [Error] Error: Problem parsing d="M42.28125,20 CNaN NaN, NaN NaN, 42.28125 20"

Comparison with my branch and beta:

[Sarronnn]

Theory about the error:

 - Coordinates? => Issue with the coordinates that are used to define the path

         - No, because both beta & my branch have the same d3 network

- Discussed with Dondi:

         - Issue could be because of Node version difference

               - Our server is on Node 10, and I am on Node 14 (Can't go lower) 

[dondi]

It turns out that @Onariaginosa can run Node 10, so she will see if the bug replicates locally for her

Update: Bug does not replicate for @Onariaginosa locally on Node 10

@dondi will seek to escalate the lambda work to see if this bug takes place under that configuration

[dondi]

@Sarronnn see if the bug can be reproduced on the Lambda installation: https://2dz4kdk52j37d7xhm6cwi4u4wq0ydwdv.lambda-url.us-east-1.on.aws

[Sarronnn]

Bug cannot be produced on the Lambda Installation. Although, the whole window seemed to be buggy..

[dondi]

Based on these findings, it looks like the root cause is the specific dependency versions that are installed when running a version of Node that is too old

This will be a non-factor going forward due to our ability to use newer versions of Node via the Lambda approach