Skip to content
This repository has been archived by the owner on Jan 30, 2025. It is now read-only.

Show actor type #10

Merged
merged 3 commits into from
Oct 2, 2024
Merged

Show actor type #10

merged 3 commits into from
Oct 2, 2024

Conversation

abefernan
Copy link
Collaborator

Closes #2.

Adds a mock function that randomly tells you if an address is an account, a contract, or a validator. The diagram renders differently depending on that type of address.

An account sends to a contract:
show-actor-type-1

A validator sends to an account:
show-actor-type-2

@abefernan abefernan requested a review from hashedone September 30, 2024 08:40
@abefernan abefernan self-assigned this Sep 30, 2024
Copy link

@hashedone hashedone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like how the getAddressType is implemented - that would be not nice even to test/present as it is inconsistent. See the comment. Could we figure out something better for the time being?

lib/chain.ts Outdated
Comment on lines 2 to 10
export function getAddressType(_address: string) {
if (Math.random() < 0.5) {
return "account";
}

return Math.random() < 0.5 ? "contract" : "validator";
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we mock it in a different way? That would be consistent between renders. Even a file with the list of contract addresses and validator addresses to hardcode/configure those temporarily would be better for testing and presentation purposes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, maybe checking if the address contains some characters? That way it'd work for any address instead of those on a list

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking this way too. Anything predictable would work, I think.

@abefernan abefernan requested a review from hashedone October 2, 2024 09:43
@abefernan abefernan force-pushed the better-react-mermaid branch from d7be3ce to 63e62d3 Compare October 2, 2024 10:09
@abefernan abefernan force-pushed the better-react-mermaid branch from 63e62d3 to 0fa660c Compare October 2, 2024 10:42
Base automatically changed from better-react-mermaid to main October 2, 2024 10:46
@abefernan abefernan merged commit 8bcfaa2 into main Oct 2, 2024
1 check passed
@abefernan abefernan deleted the show-actor-type branch October 2, 2024 10:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Better participant names in Mermaid
2 participants