feat: enhance visualization of connectors

[haoqixu]

partially implement #117

This PR enhances visualization of connectors:

• The connection between connector's exporter and receiver is visualised as a directed arrows from exporter to receiver.
• Pipeline Nodes (parentNode) are laid out based on the connector's connections. This is different from what was mentioned in the issue.

before:

after:

[vercel]

@haoqixu is attempting to deploy a commit to the OTelBin Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[haoqixu]

I have read the CLA Document and I hereby sign the CLA

[mmanciop]

Lovely :-) We'll review it ASAP!

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
otelbin	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 13, 2023 5:08pm

[mmanciop]

@haoqixu would you please enable in your fork Allowing changes to a pull request branch created from a fork, or run (cd packages/otelbin/ && npm run prettier:all) from the repo root? The linter is unhappy because of missing semicolons :-)

[mmanciop]

Overall, I like very much where the change is going. The layout you implemented has a lot going for it: it is easier to see how pipelines flow into one another, following the conventional left-to-right approach.

I have concerns about the fact that it is no longer simple to see which pipelines can receive data "from the outside" through non-connector receivers, which exports send data to the outside, which is why in #117 I was thinking of always keeping lanes vertically aligned: receivers are always to the beginning of a "line", exporters always at its end.

Nevertheless, this looks to like an excellent improvement when dealing with connectors, and I am looking forward for @bripkens to review when he is no longer under the weather.

[mmanciop]

I am also not sure how far it is realistic to go in terms of detecting connector cycles (see example), but we definitely should try not to have edges overlap with nodes.

[haoqixu]

I am also not sure how far it is realistic to go in terms of detecting connector cycles (see example), but we definitely should try not to have edges overlap with nodes.

I think it is realistic to detect cycles and I have implemented a POC. It looks like:

After I clean up the code and test it more carefully, I will update the PR.

[haoqixu]

I have rebased this PR onto the latest main and added the code for cycles detection. Here are the screenshots after update:

[bripkens]

This is looking really good @haoqixu. Great job! ❤️

Left some minor comments about the code.

Could you please visually align the arrow head of the cycle indicator edge to the arrow heads of the other edge types? That would be great.

[haoqixu]

updated:

[sonarqubecloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

2 New issues
0 Security Hotspots
No data about Coverage
9.2% Duplication on New Code

See analysis details on SonarCloud

[bripkens]

LGTM 👍

Really well done! Thank you @haoqixu!