Skip to content
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

chore: sunset unused ChildAccount type #6524

Merged
merged 1 commit into from
Mar 29, 2024
Merged

chore: sunset unused ChildAccount type #6524

merged 1 commit into from
Mar 29, 2024

Conversation

gre
Copy link
Contributor

@gre gre commented Mar 22, 2024

βœ… Checklist

  • npx changeset was attached. (not needed)
  • Covered by automatic tests. if it builds, it should be good.
  • Impact of the changes: none (unused)

πŸ“ Description

We introduced the concept of ChildAccount back in 2020 on the first implementation of Tezos which had this concept of KT Accounts. These not being strictly a token, but a "sub account of tezos", it made sense at the time to diverge from the Token Account.
Since the JS rework of tezos (2021?) as well as Tezos' sunset of kt accounts (delegation now directly happens on the main account), we no longer needed to support KT Accounts. However that type was still forgotten in our type model and became tech debt.

We can now remove it, this makes possible simplifications in the future, you can notably observe that the type SubAccount is now strictly equivalent to TokenAccount.

❓ Context


🧐 Checklist for the PR Reviewers

  • The code aligns with the requirements described in the linked JIRA or GitHub issue.
  • The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
  • There are no undocumented trade-offs, technical debt, or maintainability issues.
  • The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
  • Any new dependencies have been justified and documented.
  • Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

@gre gre requested review from a team as code owners March 22, 2024 14:59
Copy link

vercel bot commented Mar 22, 2024

The latest updates on your projects. Learn more about Vercel for Git β†—οΈŽ

Name Status Preview Comments Updated (UTC)
web-tools βœ… Ready (Inspect) Visit Preview πŸ’¬ Add feedback Mar 28, 2024 4:53pm
4 Ignored Deployments
Name Status Preview Comments Updated (UTC)
ledger-live-docs ⬜️ Ignored (Inspect) Visit Preview Mar 28, 2024 4:53pm
ledger-live-github-bot ⬜️ Ignored (Inspect) Visit Preview Mar 28, 2024 4:53pm
native-ui-storybook ⬜️ Ignored (Inspect) Visit Preview Mar 28, 2024 4:53pm
react-ui-storybook ⬜️ Ignored (Inspect) Visit Preview Mar 28, 2024 4:53pm

@live-github-bot live-github-bot bot added desktop Has changes in LLD mobile Has changes in LLM common Has changes in live-common ledgerjs Has changes in the ledgerjs open source libs cli labels Mar 22, 2024
@gre gre marked this pull request as draft March 22, 2024 15:10
@gre gre marked this pull request as ready for review March 22, 2024 16:06
@gre gre requested a review from a team as a code owner March 22, 2024 16:06
Copy link
Contributor

@sprohaszka-ledger sprohaszka-ledger left a comment

Choose a reason for hiding this comment

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

Thanks for lighten the model :D
I am not fully sure about the WalletAPI part. I'd let @Justkant give you his opinion.

For the rest, I rely on you about Tezos and Solana update (I don't have any knowledge about those chains)

/** super type that is either a token or a child account */
export type SubAccount = TokenAccount | ChildAccount;
/**
* deprecated use TokenAccount instead
Copy link
Contributor

Choose a reason for hiding this comment

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

Use jsdoc tag to highlight it in IDE * @deprecated Use TokenAccount instead

Copy link
Contributor Author

@gre gre Mar 26, 2024

Choose a reason for hiding this comment

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

@sprohaszka-ledger unfortunately can't do this due to a bug with documentation that will completely break the README doc generation. i lost half a day trying to understand what was wrong on this. I think @hedi-edelbloute is aware of this problem as it arise in the past too. very unfortunate.

documentationjs/documentation#1596

@@ -46,7 +46,7 @@ const AccountRow = ({
useEnv("HIDE_EMPTY_TOKEN_ACCOUNTS");
const currency = getAccountCurrency(account);
const parentAccount = useSelector((state: State) =>
parentAccountSelector(state, { account: account as ChildAccount }),
parentAccountSelector(state, { account: account as TokenAccount }),
Copy link
Contributor

Choose a reason for hiding this comment

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

Why force cast with a new type? The removed one should imply that the account cannot be cast, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i'm not familiar with this specific code.
I will create a ticket on Jira to investigate why we need this casting / if it can be fixed, but I think out of scope of the type simplification of this PR I think.
The flaw is in the existing code of develop, it's just that here the new ChildAccount is now TokenAccount, it seems like we loosely expect account is a token account here and we need this cast to not break the typing.

Copy link
Contributor

Choose a reason for hiding this comment

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

I mean also casting from ChildAccount (which is a specific type) to TokenAccount is quite weird as it is not the same type.

Copy link
Contributor Author

@gre gre Mar 28, 2024

Choose a reason for hiding this comment

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

ooh I see what you mean. i think it was a mistake in the past indeed, instead of ChildAccount we meant to do SubAccount.
because the parentAccountSelector takes a SubAccount out there. and the ChildAccount was type matching to be a SubAccount, the problem is that, indeed, casting hide the type issue in this place.

It isn't typed well at this selector side, it could accept an AccountLike so we get rid of this casting

export const parentAccountSelector = createSelector(
  accountsSelector,
  (_: State, { account }: { account?: SubAccount }) => (account ? account.parentId : null),
  (accounts, accountId) => accounts.find(a => a.id === accountId),
);

i'm pushing a fix.

(side note: the usecase for such a selector is very weird, we shouldn't have to infer back the parent, it should be provided in the first place... but i'm not going to look at this now)

Copy link
Member

@hedi-edelbloute hedi-edelbloute left a comment

Choose a reason for hiding this comment

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

I'm scared we someday need to use child account for family accounts with currency subAccounts, if it works i'd keep it

@gre
Copy link
Contributor Author

gre commented Mar 26, 2024

@hedi-edelbloute to port what we discussed in our DM earlier:
unfortunately we just forgot this tech debt in the past, ChildAccount being sunset since 2021, i'm almost certain that our UI have not survived the successive rework and will not support out of the box this idea from the past. We are likely to have many subtle broken parts if we think we can start reusing this and it's why it's dangerous and that we want to get rid of (similar to freshAddresses being wrong / empty for many implementations, because it's not used by anything). So, it probably would be easier to just reintroduce the concept whenever you re-need it in the future, but i think we have to sunset what is unused first.
More wider thought on the topic, but I think a better way for the future will be to flatten our accounts as much as possible and not try to introduce too much nesting. so many we also will need to double think about the idea to reintroduce this pattern. We have numerous discussion on the fact nesting created us many complexity on our current stack.

@gre gre marked this pull request as ready for review March 28, 2024 14:01
Justkant
Justkant previously approved these changes Mar 28, 2024
@@ -50,7 +50,7 @@ const fields: Field[] = [
{
title: "Operation Fees",
cell: (account, parentAccount, op) =>
["TokenAccount", "ChildAccount"].includes(account.type)
["TokenAccount"].includes(account.type)
Copy link
Contributor

Choose a reason for hiding this comment

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

could be

Suggested change
["TokenAccount"].includes(account.type)
account.type === "TokenAccount"

Copy link
Contributor

@sprohaszka-ledger sprohaszka-ledger left a comment

Choose a reason for hiding this comment

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

Some nitpicking ;)

account.type !== "ChildAccount" && account.spendableBalance
? account.spendableBalance
: account.balance;
const nested = ["TokenAccount"].includes(account.type);
Copy link
Contributor

Choose a reason for hiding this comment

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

This is simpler no?

const nested = account.type === "TokenAccount"

account.type !== "ChildAccount" && account.spendableBalance
? account.spendableBalance
: account.balance;
const balance = account.spendableBalance ? account.spendableBalance : account.balance;
Copy link
Contributor

Choose a reason for hiding this comment

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

Simpler, no ?

const balance = account.spendableBalance || account.balance

@@ -50,7 +50,7 @@ const fields: Field[] = [
{
title: "Operation Fees",
cell: (account, parentAccount, op) =>
["TokenAccount", "ChildAccount"].includes(account.type)
["TokenAccount"].includes(account.type)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why don't use === ?

@gre gre force-pushed the live-11884 branch 2 times, most recently from f69225c to 897134a Compare March 28, 2024 16:30
Copy link

socket-security bot commented Mar 28, 2024

No dependency changes detected. Learn more about Socket for GitHub β†—οΈŽ

πŸ‘ No dependency changes detected in pull request

Copy link
Contributor

@sprohaszka-ledger sprohaszka-ledger left a comment

Choose a reason for hiding this comment

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

πŸ‘

@gre gre merged commit 7cbe2f4 into develop Mar 29, 2024
56 of 59 checks passed
@gre gre deleted the live-11884 branch March 29, 2024 10:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli common Has changes in live-common desktop Has changes in LLD ledgerjs Has changes in the ledgerjs open source libs mobile Has changes in LLM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants