feat(explorer): show detailed account info based on account type#813
Draft
feat(explorer): show detailed account info based on account type#813
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
samui-wallet-web | fd08fae | Commit Preview URL Branch Preview URL |
Jan 21 2026, 11:28 AM |
beeman
force-pushed
the
beeman/account-info
branch
from
70b3449 to
8e1282e
Compare
BundleMonFiles added (3)
Files removed (3)
Files updated (21)
Unchanged files (74)
Total files change -259.14KB -22.81% Groups updated (3)
Final result: ✅ View report in BundleMon website ➡️ |
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to 70b3449 in 2 minutes and 37 seconds. Click for details.
- Reviewed
488lines of code in16files - Skipped
0files when reviewing. - Skipped posting
2draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/explorer/src/explorer-feature-account-info-token-mint.tsx:14
- Draft comment:
Avoid using @ts-expect-error; refine the types for accountData.parsed.info properties so that type errors are handled properly. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 35% vs. threshold = 50% The comment is about code that was changed/added in the diff. It's suggesting a code quality improvement - replacing@ts-expect-errorwith proper typing. This is generally a good practice and the comment is actionable. However, I need to consider: 1) Is this obvious? Using@ts-expect-erroris generally considered a code smell, so suggesting to fix it might be obvious. 2) Is this clearly requiring a code change? The rules say "Do NOT comment unless there is clearly a code change required." While better typing is preferable, the code technically works as-is. 3) The comment doesn't explain HOW to fix it, just says to "refine the types" which is somewhat vague. Looking at the additional rules about code quality refactors: "Comments that suggest code quality refactors are good! But only if they are actionable and clear." This comment suggests a refactor but doesn't provide clear guidance on how to do it. The comment is about a legitimate code quality issue (using@ts-expect-error), and code quality refactors are explicitly allowed if actionable and clear. While the comment identifies the problem, it may not be specific enough about the solution. Also, there might be a valid reason for using@ts-expect-errorhere if the upstream types are not well-defined. While code quality refactors are allowed, this comment lacks specificity about how to fix the issue. It's also possible the author is aware of the type suppression and chose it deliberately because the upstreamAccountInfoWithParsedData['data']type may not have proper definitions for the parsed token mint structure. Without seeing the type definition, we can't be sure this is fixable or that the author didn't already consider this. The comment identifies a code quality issue but lacks actionable guidance on how to fix it. Given the uncertainty about whether the upstream types can be refined and the lack of specific instructions, this comment is borderline useful but leans toward not being actionable enough to keep.
2. packages/solana-client/test/get-account-type.integration.test.ts:14
- Draft comment:
Avoid using async callbacks directly in the describe block; instead, use beforeAll for asynchronous setup. - Reason this comment was not posted:
Marked as duplicate.
Workflow ID: wflow_mCvd28eu0C0WIcLb
You can customize 
beeman
force-pushed
the
beeman/account-info
branch
from
8e1282e to
0436802
Compare
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed 0436802 in 2 minutes and 50 seconds. Click for details.
- Reviewed
486lines of code in16files - Skipped
0files when reviewing. - Skipped posting
3draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/solana-client/src/get-account-type.ts:13
- Draft comment:
BPF_LOADER case returns 'system-program', but the integration test expects 'system'. Please reconcile this inconsistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment references an integration test that is not shown in the diff. I have no way to verify whether the integration test actually expects 'system' for BPF_LOADER accounts, or if such a test even exists. The code in the diff appears internally consistent - 'system-program' is a valid return type defined in the AccountType union. Without being able to see the test file, I cannot confirm this is a real issue. According to my instructions, if understanding the comment requires more context (such as seeing other files), I should delete the comment. This clearly requires seeing the test file to verify the claim. Perhaps the reviewer has access to the integration test and knows there's a real inconsistency. Maybe this is a legitimate bug that needs to be fixed, and I'm being too strict by requiring all evidence to be in the diff itself. While the reviewer may have seen the test, my instructions are clear: I must see STRONG EVIDENCE in the diff that the comment is correct. The comment references external files (integration tests) that are not part of this diff. Without being able to verify the claim, I cannot confirm this is a real issue versus a misunderstanding or outdated information. Delete this comment because it references integration tests that are not visible in the diff, and I cannot verify the claimed inconsistency. The code in the diff itself appears internally consistent.
2. packages/explorer/src/explorer-feature-account-info-token-account.tsx:14
- Draft comment:
Consider refining the types for accountData.parsed.info to avoid using @ts-expect-error. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment says "Consider refining the types" which is a suggestion, not a clear directive. It's asking the author to potentially improve type safety, but it's not pointing out a bug or a clear issue. The use of@ts-expect-erroris intentional by the author (they explicitly added these comments), suggesting they're aware of the typing issue. The comment doesn't provide specific guidance on HOW to refine the types or what the actual problem is. This feels like a "nice to have" code quality suggestion rather than identifying a real problem. According to the rules, comments should not be speculative or purely informative - they should clearly indicate a code change is required. The author explicitly added@ts-expect-errorcomments, which suggests they made a conscious decision about the typing approach. Perhaps there's a legitimate reason the types can't be easily refined (e.g., the upstream type definition is incomplete or complex). The comment might be valid if proper typing is actually achievable and important. While there might be a legitimate reason for the type suppressions, the comment uses "Consider" which makes it a suggestion rather than a clear requirement. It doesn't demonstrate that refining the types is definitely possible or necessary. Without seeing the actual type definition ofAccountInfoWithParsedData['data'], we can't verify if this is actionable. This comment should be deleted. It uses soft language ("Consider") and doesn't provide clear, actionable guidance. It's essentially asking the author to improve code quality without demonstrating that there's a definite issue or providing specific direction on how to fix it.
3. packages/explorer/src/explorer-feature-account-info-token-mint.tsx:14
- Draft comment:
Avoid using @ts-expect-error here; consider updating the type definitions for accountData.parsed.info for better type safety. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This comment is suggesting a code quality improvement - to fix the type definitions rather than suppress errors. However, looking at the rules, I need to consider: 1) Is this actionable and clear? It's somewhat vague - it says "consider updating" which is not a strong directive. 2) The author clearly made a deliberate choice to use@ts-expect-errorhere (they added it in new code). 3) The comment doesn't provide specific guidance on HOW to fix the types or what the correct types should be. 4) This could be considered speculative - we don't know if updating the type definitions is feasible or if there's a good reason for the current approach. 5) The rules say comments should be actionable and clear for code quality refactors, but this is more of a general suggestion without specific implementation guidance. The author might have a valid reason for using@ts-expect-errorhere - perhaps the type definitions come from an external library they don't control, or the parsed data structure is dynamic and hard to type properly. The comment might be pointing out a legitimate technical debt issue that should be addressed. While there might be legitimate reasons to improve typing, the comment is too vague and doesn't provide actionable guidance. It uses "consider" which is a weak suggestion, and doesn't explain how to fix it or what the correct approach would be. The author clearly made a deliberate choice here, and without more specific guidance, this comment is not actionable enough to be useful. This comment should be deleted. It's a vague suggestion ("consider updating") without specific, actionable guidance on how to fix the issue. The author deliberately added these@ts-expect-errorcomments, and the review comment doesn't provide clear enough direction to be useful.
Workflow ID: wflow_xlhbTpC6zLmFeFp5
You can customize
beeman
force-pushed
the
beeman/account-info
branch
7 times, most recently
from
7ad5147 to
9f53fb3
Compare
1 task
beeman
force-pushed
the
beeman/account-info
branch
from
9f53fb3 to
7c8fbe7
Compare
Contributor
|
@beeman What's the status of this one? |
Member
Author
beeman
force-pushed
the
beeman/account-info
branch
5 times, most recently
from
3d4a2ab to
2c6c60b
Compare
beeman
force-pushed
the
beeman/account-info
branch
from
2c6c60b to
fd08fae
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
This PR implements the work to make the account pages in the explorer adapt to their type.
The type of account is detected through the
getAccountTypein the solana-client package. In the future we'll be able to add more types here and handle rendering and logic of certain accounts based on that type.Screenshots / Video
Important
Add detailed account information display in explorer based on account type using
getAccountType.ExplorerFeatureAccountInfoContentinexplorer-feature-account-info-content.tsxusesgetAccountTypeto render account-specific components.ExplorerFeatureAccountInfoTokenAccountandExplorerFeatureAccountInfoTokenMintadded for rendering token account and mint details.ExplorerFeatureAccountInfoinexplorer-feature-account-info.tsxintegrates account type display and content rendering.ExplorerFeatureAccountOverviewupdated to useExplorerFeatureAccountInfo.ExplorerUiDetailGridadded for layout consistency.explorer.jsoninlocales/enandlocales/esfor new labels.resources.d.tsto include new i18n keys.SYSTEM_ACCOUNT,NATIVE_LOADER,BPF_LOADERtoconstants.ts.getAccountInfoandgetAccountTypeinget-account-info.integration.test.tsandget-account-type.integration.test.ts.This description was created by
for 0436802. You can customize this summary. It will automatically update as commits are pushed.