Update types lib

packages/types-cryptoassets/src/index.ts

@@ -90,12 +90,10 @@ export type CryptoCurrency = CurrencyCommon & {
   supportsNativeSegwit?: boolean;
   // if defined this coin is a testnet for another crypto (id)};
   isTestnetFor?: string;
-  // TODO later we could express union of types with mandatory bitcoinLikeInfo for "bitcoin" family...
   bitcoinLikeInfo?: {
     P2PKH: number;
     P2SH: number;
     XPUBVersion?: number;
-    // FIXME optional as we miss some data to fill
     hasTimestamp?: boolean;
   };
   ethereumLikeInfo?: {

packages/types-live/src/account.ts

@@ -6,25 +6,20 @@ import type {
 } from "@ledgerhq/types-cryptoassets";
 import type { OperationRaw, Operation } from "./operation";
 import type { DerivationMode } from "./derivation";
-
-import type {
-  BalanceHistory,
-  BalanceHistoryRaw,
-  PortfolioRange,
-} from "./portfolio";
 import type { SwapOperation, SwapOperationRaw } from "./swap";
 import type { NFT, NFTRaw } from "./nft";
+
 // This is the old cache and now DEPRECATED (pre v2 portfoli)
-export type BalanceHistoryMap = Partial<Record<PortfolioRange, BalanceHistory>>;
-export type BalanceHistoryRawMap = Record<PortfolioRange, BalanceHistoryRaw>;
 export type GranularityId = "HOUR" | "DAY" | "WEEK";
+
 // the cache is maintained for as many granularity as we need on Live.
 // it's currently an in memory cache so there is no problem regarding the storage.
 // in future, it could be saved and we can rethink how it's stored (independently of how it's in memory)
 export type BalanceHistoryCache = Record<
   GranularityId,
   BalanceHistoryDataCache
 >;
+
 // the way BalanceHistoryDataCache works is:
 // - a "cursor" date which is the "latestDate" representing the latest datapoint date. it's null if it never was loaded or if it's empty.
 // - an array of balances. balances are stored in JSNumber even tho internally calculated with bignumbers because we want very good perf. it shouldn't impact imprecision (which happens when we accumulate values, not when presenting to user)
@@ -34,7 +29,10 @@ export type BalanceHistoryDataCache = {
   latestDate: number | null | undefined;
   balances: number[];
 };
-// A token belongs to an Account and share the parent account address
+
+/**
+ * A token belongs to an Account and share the parent account address
+ */
 export type TokenAccount = {
   type: "TokenAccount";
   id: string;
@@ -50,8 +48,6 @@ export type TokenAccount = {
   operations: Operation[];
   pendingOperations: Operation[];
   starred: boolean;
-  // DEPRECATED! it will be dropped when switching to Portfolio V2
-  balanceHistory?: BalanceHistoryMap;
   // Cache of balance history that allows a performant portfolio calculation.
   // currently there are no "raw" version of it because no need to at this stage.
   // could be in future when pagination is needed.
@@ -63,7 +59,10 @@ export type TokenAccount = {
     value: string;
   }>;
 };
-// A child account belongs to an Account but has its own address
+
+/**
+ * A child account belongs to an Account but has its own address.
+ */
 export type ChildAccount = {
   type: "ChildAccount";
   id: string;
@@ -78,19 +77,35 @@ export type ChildAccount = {
   operationsCount: number;
   operations: Operation[];
   pendingOperations: Operation[];
-  // DEPRECATED! it will be dropped when switching to Portfolio V2
-  balanceHistory?: BalanceHistoryMap;
   // Cache of balance history that allows a performant portfolio calculation.
   // currently there are no "raw" version of it because no need to at this stage.
   // could be in future when pagination is needed.
   balanceHistoryCache: BalanceHistoryCache;
   // Swap operations linked to this account
   swapHistory: SwapOperation[];
 };
+
+/**
+ *
+ */
 export type Address = {
   address: string;
   derivationPath: string;
 };
+
+/**
+ * Account type is the main level account of a blockchain currency.
+ * Each family maybe need an extra field, to solve this, you can have some subtyping like this:
+
+
+    export type BitcoinAccount = Account & { bitcoinResources: BitcoinResources }
+
+and all parts where we would need it, we would need to cast,
+
+    const bitcoinAccount = account as BitcoinAccount;
+
+and that BitcoinAccount type would be part of a coin integration family specific indeed.
+ */
 export type Account = {
   type: "Account";
   // unique account identifier
@@ -153,9 +168,6 @@ export type Account = {
   pendingOperations: Operation[];
   // used to know when the last sync happened
   lastSyncDate: Date;
-  // A configuration for the endpoint to use. (usecase: Ripple node)
-  // FIXME drop and introduce a config{} object
-  endpointConfig?: string | null | undefined;
   // An account can have sub accounts.
   // A sub account can be either a token account or a child account in some blockchain.
   // They are attached to the parent account in the related blockchain.
@@ -169,44 +181,37 @@ export type Account = {
   // "account" is the primary account that you use/select/view. It is a `AccountLike`.
   // "parentAccount", if available, is the contextual account. It is a `?Account`.
   subAccounts?: SubAccount[];
-  // balance history represented the balance evolution throughout time, used by chart.
-  // This is to be refreshed when necessary (typically in a sync)
-  // this is a map PER granularity to allow a fast feedback when user switch them
-  // DEPRECATED! it will be dropped when switching to Portfolio V2
-  balanceHistory?: BalanceHistoryMap;
   // Cache of balance history that allows a performant portfolio calculation.
   // currently there are no "raw" version of it because no need to at this stage.
   // could be in future when pagination is needed.
   balanceHistoryCache: BalanceHistoryCache;
-
-  // FIXME how to solve this?
-  /*
-  // On some blockchain, an account can have resources (gained, delegated, ...)
-  bitcoinResources?: BitcoinResources;
-  tronResources?: TronResources;
-  cosmosResources?: CosmosResources;
-  algorandResources?: AlgorandResources;
-  polkadotResources?: PolkadotResources;
-  tezosResources?: TezosResources;
-  elrondResources?: ElrondResources;
-  cryptoOrgResources?: CryptoOrgResources;
-  */
-
   // Swap operations linked to this account
   swapHistory: SwapOperation[];
   // Hash used to discard tx history on sync
   syncHash?: string;
   // Array of NFTs computed by diffing NFTOperations ordered from newest to oldest
   nfts?: NFT[];
 };
+
+/**
+ * super type that is either a token or a child account
+ */
 export type SubAccount = TokenAccount | ChildAccount;
+/**
+ * One of the Account type
+ */
 export type AccountLike = Account | SubAccount;
-// Damn it flow. can't you support covariance.
-export type AccountLikeArray =  // $FlowFixMe wtf mobile
+/**
+ * an array of AccountLikes
+ */
+export type AccountLikeArray =
   | AccountLike[]
   | TokenAccount[]
   | ChildAccount[]
   | Account[];
+/**
+ *
+ */
 export type TokenAccountRaw = {
   type: "TokenAccountRaw";
   id: string;
@@ -220,14 +225,16 @@ export type TokenAccountRaw = {
   balance: string;
   spendableBalance?: string;
   compoundBalance?: string;
-  balanceHistory?: BalanceHistoryRawMap;
   balanceHistoryCache?: BalanceHistoryCache;
   swapHistory?: SwapOperationRaw[];
   approvals?: Array<{
     sender: string;
     value: string;
   }>;
 };
+/**
+ *
+ */
 export type ChildAccountRaw = {
   type: "ChildAccountRaw";
   id: string;
@@ -241,10 +248,12 @@ export type ChildAccountRaw = {
   operations: OperationRaw[];
   pendingOperations: OperationRaw[];
   balance: string;
-  balanceHistory?: BalanceHistoryRawMap;
   balanceHistoryCache?: BalanceHistoryCache;
   swapHistory?: SwapOperationRaw[];
 };
+/**
+ *
+ */
 export type AccountRaw = {
   id: string;
   seedIdentifier: string;
@@ -271,22 +280,16 @@ export type AccountRaw = {
   lastSyncDate: string;
   endpointConfig?: string | null | undefined;
   subAccounts?: SubAccountRaw[];
-  balanceHistory?: BalanceHistoryRawMap;
   balanceHistoryCache?: BalanceHistoryCache;
-  // FIXME
-  /*
-  bitcoinResources?: BitcoinResourcesRaw;
-  tronResources?: TronResourcesRaw;
-  cosmosResources?: CosmosResourcesRaw;
-  algorandResources?: AlgorandResourcesRaw;
-  polkadotResources?: PolkadotResourcesRaw;
-  elrondResources?: ElrondResourcesRaw;
-  tezosResources?: TezosResourcesRaw;
-  cryptoOrgResources?: CryptoOrgResourcesRaw;
-  */
   swapHistory?: SwapOperationRaw[];
   syncHash?: string;
   nfts?: NFTRaw[];
 };
+/**
+ *
+ */
 export type SubAccountRaw = TokenAccountRaw | ChildAccountRaw;
+/**
+ *
+ */
 export type AccountRawLike = AccountRaw | SubAccountRaw;

packages/types-live/src/bridge.ts

@@ -16,35 +16,61 @@ import type { Operation } from "./operation";
 import type { DerivationMode } from "./derivation";
 import type { SyncConfig } from "./pagination";
 
+/**
+ *
+ */
 export type ScanAccountEvent = {
   type: "discovered";
   account: Account;
 };
-// more events will come in the future
+/**
+ * more events will come in the future
+ */
 export type ScanAccountEventRaw = {
   type: "discovered";
   account: AccountRaw;
 };
-// unique identifier of a device. it will depends on the underlying implementation.
+
+/**
+ * unique identifier of a device. it will depends on the underlying implementation.
+ */
 export type DeviceId = string;
+
+/**
+ *
+ */
 export type PreloadStrategy = Partial<{
   preloadMaxAge: number;
 }>;
 
+/**
+ *
+ */
 export type BroadcastArg0 = {
   account: Account;
   signedOperation: SignedOperation;
 };
+
+/**
+ *
+ */
 export type SignOperationArg0<T> = {
   account: Account;
   transaction: T;
   deviceId: DeviceId;
 };
+
+/**
+ *
+ */
 export type SignOperationFnSignature<T> = (
   arg0: SignOperationArg0<T>
 ) => Observable<SignOperationEvent>;
 export type BroadcastFnSignature = (arg0: BroadcastArg0) => Promise<Operation>;
-// Abstraction related to a currency
+
+/**
+ *
+ */
 export interface CurrencyBridge {
   // Preload data required for the bridges to work. (e.g. tokens, delegators,...)
   // Assume to call it at every load time but as lazy as possible (if user have such account already AND/OR if user is about to scanAccounts)

packages/types-live/src/nft.ts

@@ -1,7 +1,13 @@
 import type BigNumber from "bignumber.js";
 
+/**
+ *
+ */
 export type NFTStandards = "ERC721" | "ERC1155";
 
+/**
+ *
+ */
 export type NFT = {
   // id crafted by live
   id: string;
@@ -17,12 +23,21 @@ export type NFT = {
   };
 };
 
+/**
+ *
+ */
 export type NFTRaw = Omit<NFT, "amount"> & {
   amount: string;
 };
 
+/**
+ *
+ */
 export type NFTMetadataLinksProviders = "opensea" | "rarible" | "etherscan";
 
+/**
+ *
+ */
 export type NFTMetadataResponse = {
   status: 200 | 404 | 500;
   result?: {

packages/types-live/src/operation.ts

@@ -1,6 +1,9 @@
 import type { BigNumber } from "bignumber.js";
 import { NFTStandards } from "./nft";
 
+/**
+ *
+ */
 export type OperationType =
   | "IN"
   | "OUT"
@@ -36,6 +39,10 @@ export type OperationType =
   // NFT
   | "NFT_IN"
   | "NFT_OUT";
+
+/**
+ *
+ */
 export type Operation = {
   // unique identifier (usually hash)
   id: string;
@@ -88,6 +95,10 @@ export type Operation = {
   // Operations related to ERC721 | ERC1155 tokens
   nftOperations?: Operation[];
 };
+
+/**
+ *
+ */
 export type OperationRaw = {
   id: string;
   hash: string;

packages/types-live/src/pagination.ts

@@ -1,9 +1,11 @@
-// A pagination config holds the user's pagination state
-// this is a state that usually should leave during the app lifecycle, but is not persisted
-// it drives the number of operations to poll in accounts
-// when a user paginate more, the number should accordingly be incremented
-// The UI should manage scrolling ahead of time (e.g. if 30 ops is displayed and UI have pages of 20 ops, the UI can already request to poll 70 ops so it have 2 pages in advance)
-// The UI must always do max() to keep the increasing the counter and not going back to lower value: that optim the sync to not recompute things too much
+/**
+ * A pagination config holds the user's pagination state
+ * this is a state that usually should leave during the app lifecycle, but is not persisted
+ * it drives the number of operations to poll in accounts
+ * when a user paginate more, the number should accordingly be incremented
+ * The UI should manage scrolling ahead of time (e.g. if 30 ops is displayed and UI have pages of 20 ops, the UI can already request to poll 70 ops so it have 2 pages in advance)
+ * The UI must always do max() to keep the increasing the counter and not going back to lower value: that optim the sync to not recompute things too much
+ */
 export type PaginationConfig = {
   // operations to pull for each account
   operationsPerAccountId?: Record<string, number>;