Front-end bug fixes, GraphView tweaks #79
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #59: Updates the
Load
button in theModal.Footer
to be disabled if the Node has not been executed (i.e.!= 'complete'
) and therefore no data available. The same status message appears whether there is data or not. For cases where there is a large file to load, areact-spinners-css
Component now appears instead of the "Loading data..." message.Fixes #60: Increased the
max-width
attribute for.modal-dialog
which also affects the non-GraphView windows. This is great for the case where there is a large data file to display, but not great for smaller files/other Modal windows. I couldn't easily target a child of the.modal-dialog
so I committed as-is.Part of this fix also includes a clean-up of the
computeWidths
function to make the row/column names clearer. It also calculates themaxWidth
of the Grid which allows to dynamically adjust the size for smaller data files. The default size has been bumped from 480x150 to 600x1000.The grid style has also been tweaked slightly to shade every other row (and not alternate by columns) and adds a slight border on the edges.
Fixes #74: Adjusts the API call so that the NetworkX representation on the back will always store an edge from
outPort -> inPort
regardless of whether the user creates the edge in reverse.