-
Notifications
You must be signed in to change notification settings - Fork 0
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
Bipartite network api update #765
Conversation
side note.. seems the bipartitenetwork viz is maybe more properly called a correlationbipartitenetwork ?? not urgent obviously, just a thought i had while looking at this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's important we separate the data we use to make the network from the drawing of the network. This concept will become more crucial as we get more data for nodes and links.
Currently there is a BipartiteNetworkData
type defined in both the components
and eda
libraries. They are currently kept in sync (there's a long discussion about this in another pr if you're interested). But the point is that I think we should un-sync them. The bipartite data coming from the backend should remain as BipartiteNetworkData
with the api changes, and then the components
type should be the actual network, not the data. So it should say "strokeWidth" instead of weight
, for example. I want to call that type BipartiteNetwork
but that could be confusing with the component being named the same thing. @dmfalke might have an opinion here.
At the very least, if we do not decide to go the above route, i think there are some more strokeWidth
instances in the components
library that should be updated. For example the Link
component. I would guess when you tested the changes all the links were drawn with the same stroke width?
...eda/src/lib/core/components/visualizations/implementations/BipartiteNetworkVisualization.tsx
Outdated
Show resolved
Hide resolved
...eda/src/lib/core/components/visualizations/implementations/BipartiteNetworkVisualization.tsx
Show resolved
Hide resolved
I'd be curious to read through the other discussion. And I have questions about the stroke vs weight thing for the component, but I'll save them for Mon probably |
ok. so i changed some names to separate the viz and component types as requested. i think given how things are, its reasonable. though i do wonder if were potentially backing ourselves into a corner. are we very confident the component will never need to know about the underlying data? that will always be either the backend or the vizs job? given the way weve engineered things so far im ok w continuing w that assumption, just made me a bit nervous. |
Yes i think from a philosophical standpoint the component should not know about the data. It should be only drawing a network, exactly as given. It's everyone else's job to provide the context, and let the component be totally independent. There might be something that breaks that idea someday, but for now this setup seems like it should best handle all of our use cases. |
I'm not sure which type you want to call |
@dmfalke sounds good. I added this renaming task to the bipartite network polishing gh issue. |
Great. I wonder if there are other components that should have |
resolves #764
this will keep from breaking things that are currently working. idk if there were other changes you were anticipating..