Refactor Firefly library

[maxwellmattryan]

Firefly lib Refactor - Overview

Other Docs

• Phase 01 - core functionality

Overview

With the upcoming features planned for the network (e.g. voting, digital assets) it'll be important to place Firefly in a position where it is more easily extendable to support user interaction for said features.

At the moment we have most of the business logic in shared/lib in a flat hierarchy.
This sometimes leads to files with 1000+ lines of code where it becomes difficult to find or modify functions, determine best placement for a new function, etc. It also makes it more likely for a developer to re-implement a function that is already there.

This restructure proposal defines a more hierarchical structure to shared/lib that will allow the code to be more easily extendable and maintainable while also being DRY, loosely-coupled, and modular. The files will be smaller and more specifically named, making it easier to locate functionality that one may need.

Modules

The basic structure will be made of pseduo-modules, or module-like directories containing source code for a particular mechanism, system, or functionality.

At the heart will be the core module, containing functionality that is central to the app in some way (e.g. routing, platform-based logic, i18n). The next module is common, which is to be used by any <feature> module. The <feature> modules are isolated collections of source code for a particular functionality in Firefly (e.g. digital assets, voting).

Structure

The basic structure of a module will look like:

module/
    # constants used throughout the module
    constants/
        some-logic.ts
        more-logic.ts
    # enumerators used throughout the module
    enums/
        some.enum.ts
        another.enum.ts
    # interface definitions*
    interfaces/
        some.interface.ts
        another.interface.ts
    # Svelte store variables
    stores/
        some.store.ts
        another.store.ts
    # unit and integrations tests relevant to module
    tests/
        some-logic.test.ts
        more-logic.test.ts
    # type definitions for the data used in the module
    types/
        some.type.ts
        another.type.ts
    some-logic.ts
    more-logic.ts

* Right now we are using interfaces for both purely data objects and purely functional objects. It might be best to separate these and use types for data-only and interfaces for functional objects.

Modules should support nesting, although for the sake of clean and concise imports it is (probably) best to use a maximum folder-nesting depth of 2*:

module/
    constants/
    enums/
    interfaces/
    stores/
    tests/
    types/
    *.ts
    ...
    sub-module/
        constants/
        enums/
        interfaces/
        stores/
        tests/
        types/
        *.ts
        ...

* This is likely for specific cases either where the source files are large (i.e. migration.ts and wallet.ts) or the functionality is going to be within the core module (i.e. app, network).

Responsibilities

• core
  • will contain logic for actor-related things (currently in lib/wallet.ts)
  • will contain platform-related logic, specifically for Electron and Capacitor
  • will contain app-related logic and tasks (e.g. login / logout, routing, updating, settings, i18n) (in some submodules)
  • will contain helper and util functions
  • will contain API logic currently in lib/shell
• common
  • will contain contants that are used app-wide
  • will contain profile-related functionality (e.g. creation, updating)
  • will handle common app functionality (e.g. popups, notifications)
  • will contain market functionality
  • will contain chart functionality
  • will handle all network and client operations (in submodule)
  • will handle all wallet operations including API communications, transactions, etc. (in submodule)
• digital-assets
  • will contain logic for digital assets (e.g. NFTs and colored coins)
    • NOTE: This will require new changes for wallet.rs.
• voting (this assumes a standalone feature rather than a simpler implementation)
  • will contain API logic for voting*

* It is unsure how the wallet.rs API will look for these, especially as it's being redesigned at the moment.

Organization

The following directory structure will be in packages/shared/lib:

• core/
  • app/
    • constants/
      • updater.ts
    • stores/
      • app.store.ts
      • settings.store.ts
      • updater.store.ts
    • tests/
      • *.(test|spec).ts
      • ...
    • types/
      • app.type.ts
    • app.ts
    • settings.ts
    • updater.ts
  • constants/
    • time.ts
  • shell/
    • error-logger.ts
    • wallet-api.ts
    • wallet-errors.ts
  • stores/
    • router.store.ts
  • tests/
    • *.(test|spec).ts
    • ...
  • types/
    • electron.type.ts
    • error.type.ts
    • event.type.ts
    • i18n.type.ts
    • icon.type.ts
    • notification.type.ts
    • route.type.ts
  • actions.ts
  • actor.ts
  • bridge.ts
  • electron.ts
  • errors.ts
  • helpers.ts
  • i18n.ts
  • router.ts
  • utils.ts
  • validator.ts
• common/
  • constants/
    • chart.ts
    • market.ts
    • profile.ts
      • NOTE: The constant MAX_PROFILE_NAME_LENGTH is in lib/wallet.ts.
  • network/
    • constants/
      • network.ts
      • node.ts
        • NOTE: Some constants are currently in lib/migration.ts.
    • stores/
      • status.store.ts
    • tests/
      • *.(test|spec).ts
      • ...
    • types/
      • client.type.ts
      • message.type.ts
      • network.type.ts
      • node.type.ts
    • network.ts
    • status.ts
  • stores/
    • chart.store.ts
    • market.store.ts
    • notification.store.ts
    • popup.store.ts
    • profile.store.ts
      • NOTE: This needs to contain walletPin, which 1) should be renamed to profilePin and 2) is currently in lib/app.ts.
      • NOTE: This needs to contain walletSetupType, which 1) should be renamed to profileSetupType and 2) is currently in lib/router.ts.
  • tests/
    • *.(test|spec).ts
    • ...
  • types/
    • chart.type.ts
    • icon.type.ts
    • market.type.ts
    • profile.type.ts
  • wallet/*
    • constants/
      • account.ts
      • dust.ts
      • stronghold.ts
      • storage.ts
    • migration/
      • constants/
        • bundle.ts
        • migration.ts
      • stores/
        • migration.store.ts
      • tests/
        • *.(test|spec).ts
        • ...
      • types/
        • bundle.type.ts
        • migration.type.ts
      • bundle.ts
      • migration.ts
    • stores/
      • ledger.store.ts
      • stronghold.store.ts
      • password.store.ts
      • wallet.store.ts
        • NOTE: sendParams needs to be in this file instead of app.ts, although not sure if this will affect deep linking.
    • tests/
      • *.(test|spec).ts
      • ...
    • types/
      • account.type.ts
      • address.type.ts
      • currency.type.ts
      • ledger.type.ts
      • migration.type.ts
      • mnemonic.type.ts
      • output.type.ts
    • account.ts
    • api.ts
    • bech32.ts
    • currency.ts
    • ledger.ts
    • mnemonic.ts
    • password.ts
    • stronghold.ts
    • storage.ts
    • units.ts
  • chart.ts
  • deep-linking.ts
    • NOTE: Deep linking has the potential to effect the entire app, so it should be in common.
  • market.ts
  • notifications.ts
  • popup.ts
  • profile.ts
• digital-assets/
  • ...
• voting/
  • ...

* I initially had this as a <feature> module, but I think it belongs in common since it will most likely be used by other features such as voting, digital assets, a contact system, etc.

CAUTION: Please take note of the following:

• Modules or source files in core must NOT depend on anything unless it is also in core.
• Modules or source files in common must NOT depend on any <feature> modules; only core.
• Modules or source files in <feature> modules must NOT depend on any other <feature> modules; only common, core, or the same module

Relationships

TODO: Create module relationship / dependency diagram

I am also proposing that we start using interfaces for grouping collections of functions, which will...

• make it easier to reason about the application as logic will be grouped in similar places
• significantly reduce the number of import statements made across the board
• make it easier to adhere to the S.O.L.I.D. principles, which are:

  • Single Responsibility Principle (SRP): modules and source files should have one reason to change and should be responsible for only one actor. If a source code file or module is subject to change because of multiple reasons (could be b/c of other functions, or a bug, i.e. anything), then it means that there is logic that should be separated.

    It is easiest to do this coming up with a data flow for a process within the application. In Firefly, transactions are displayed in the wallet dashboard, however we have been talking about adding a feature for exporting them as .pdf, .csv, etc. We could say that there are two processes for this: 1) syncing the account transactions and 2) presenting that data in a browser- and printer-friendly format. The two objects here could be AccountSynchronizer, containing logic for syncing an account, namely its messages, and MessagePresenter, containing logic for displaying or exporting the data in a particular format. Perhaps a MessageExporter is used by the MessagePresenter containing different logic for the different formats (HTML, PDF, CSV, etc.).

  • Open-Closed Principle (OCP): modules and source files should be open for extension but closed for modification. This means that adding new features to Firefly should result in little (ideally none) modification of existing functionality. This is accomplished this by separating modules and source code that changes for different reasons (the SRP) then properly structuring the dependencies them (the Dependency Inversion Principle or DIP).

  • Liskov Substitution Principle (LSP): if an an object of type S can be swapped with in object of type T in a program P where the behavior of P remains the same then S is a subtype of T. The aim of LSP is to create as much interoperability between types as possible, which results in adding fewer mechanisms (i.e. checks, guards, etc.) in the logic for handling different types.

    I think a great example of this in Firefly is how we check for the type of a profile when doing different things. This makes more sense in the Svelte components as it's UI-related logic and less so in other parts of the business logic. It would quite fantastic if we were able to specify the profile type and just call a function that is defined by separate interfaces for Ledger and software profiles. Doing so would keep the code less polluted with extra unneeded logic in places, putting it in grouped interfaces.

  • Interface Segregation Principle (ISP): this refers to isolating operations into interfaces that exist between the operations themselves and the actors that use them. This helps us avoid inadvertent dependencies on source code that we don't necessarily need.

  • Dependency Inversion Principle (DIP): when source code dependencies refer only to abstractions and not concretions is when a system can be most flexible. This cannot be applied all the time, so it's worth noting that this particularly applies to volatile concrete objects, which are artifacts being actively developed or some type of frequent change.

    This one can be broken down into a few specific coding practices:

    • Do NOT use volatile concrete classes, use interfaces instead.
    • Do NOT inherit or implement from volatile concrete classes.
    • Do NOT override concrete functions; overriding requires one to inherit the dependencies, so the function should be made abstract and implemented multiple times as needed.
    • Do NOT mention the name of a concrete and volatile class or code.

It is important that we try and adhere to S.O.L.I.D principles when making this refactor to help keep the architecture clean. The five points are:

Benefits

• Firefly will be more extendable and maintainable, so both adding new features and modifying existing ones will become even easier, speeding up product momentum.
• The code will be DRY-er, more composable (especially if we stick to a functional-style), and more isolated, making searching for source code easier.
• Depending on how the plugin system will work, refactoring this way would likely make it easier to implement a plugin system for community developers to build on smoothly. If our business logic is isolated more cleanly, we can expose it with more granularity if we need to. Not sure how feasible it would be to have the lib on the npm registry.
• As the size of the team increases, it'll be important to avoid merge conflicts with one another. If large source code files and refactored into smaller isolated source code files, then there's less of a chance for merge conflicts.

Drawbacks / Concerns

• core really needs to be the core functionality needed for the app. Let's be cautious that it doesn't become a bloated module / directory.
• It may be easy to create a folder organization that is too hierarchical... be careful and stick to a max nested depth of 2.
• It may be best to use barrel importing to reduce the number of import statements in component files, although the number of things imported may be roughly the same. If we don't use barrel imports, then our import statements might look something like import { ... } from 'shared/lib/wallet/migration/migration.ts' instead of import { ... } from 'shared/lib/wallet/migration'
  • Using these will drastically reduce the number of import statements we make across the codebase.
• Path aliases will likely become more important, and this is something we should really look at solving. Although the imports aren't too much longer, they could and would really benefit from being cleaned up by path aliases.
  • using @lib/... is enough IMO, but we can also make them shorter and more specific such as @core/... and @common/network/...
  • main problem is getting paths to resolve correctly for building
• logout() may potentially be problematic if it's in core (or common) because it resets a bunch of state across the entire app. We'll need to figure out a way to break this dependency somehow or put the logic in a better place (is there a better place?)

Questions

• Not sure of which term to use or how to group the three main assets planned for the network: IOTA tokens, colored coins, and NFTs...

  wallet (IMO) doesn't sound quite right when being used to mean all three; it feels more like it represents strictly money rather than other assets. portfolio is a nice word to use that works for NFTs and colored coins, perhaps even IOTA tokens too. However wallet could also be seen as meaning the collection of transactable tokens, which would mean colored coins and IOTA tokens; NFTs are intended more for collecting rather than transacting necessarily.

• Should the code for wallet also be a <feature> module? I think it depends how the upcoming features will be implemented into Firefly, i.e. if they are separate features with dedicated pages / tabs (left-hand side) then they should be standalone <feature> modules. However since functionality in wallet would be used elsewhere then it should be in common right?

• We should stick to one method of using the wallet.rs API; right now there are instances where it's called directly from both other business logic and UI components using api.syncAccounts(...) or indirectly with a wrapper like asyncSyncAccounts(...).

  With wrappers, it'll be easier to hide implementation details, which is important, however having an api object is nice as we can more easily see available functionality (and handle different outcomes for the same API call if needed). In cases where functionality is duplicated, it's probably best defined as a function to make it DRY-er, but at the same time having a consistent method of API implementation is ideal.

Other Improvements

• We should be using consistent and clear names for things through the domain (names for files, variables, functions, i.e. everything), while being cautious to not interchangeably use a term to describe something that it's not
  • e.g. using "account" to really mean a Firefly "profile", because "account" is used elsewhere to mean a "wallet" within a "profile"... it can get confusing quickly
  • in app.ts:

    /**
     * Wallet access pin
     */
    export const walletPin = writable<number>(null) // should be profilePin

  • in network.ts:

    export const updateAccountNetworkSettings = ( // should be updateProfileNetworkSettings
        automaticNodeSelection: boolean,
        includeOfficialNodes: boolean,
        nodes: Node[],
        primaryNodeUrl: string,
        localPow: boolean
    ): void => {
        updateProfile('settings.automaticNodeSelection', automaticNodeSelection)
        updateProfile('settings.includeOfficialNodes', includeOfficialNodes)
    
        const disabledNodes = nodes.filter((n) => n.disabled).map((n) => n.url)
        updateProfile('settings.disabledNodes', disabledNodes)
    
        let clientNodes = []
        let officialNodes = getOfficialNodes()

• Using a more functional style of programming
  • write functions with deterministic output (an input will always result in the same output)
  • keep side-effects to an absolute minimum
  • think carefully about return types of functions (is it always gonna result in this object or can it error, if so we should make the return type more explicit)

[nicole-obrien]

Great writeup Matt. A couple of opinions of mine:

• Rather than nesting modules in modules I think we flatten it slightly and have category folders within the high level folders of a module. i.e. module/interfaces/category/file.interface.ts that way we can categories them into other logical categories than the sub modules and remove the ownership of the file from that module, as it is likely it can be used more globally.
• If we categories interfaces into categories we can have one interface per file too, and still keep some organisation.
• I am a fan of including the .file-type.ts in the file name. i.e. .interface.ts
• Need to consider a folder structure for svelte components too. I really like the atomic design principles, and would be good include something like that in our practice.
• I think the point on naming of wallet / profile etc. needs its own discussion. I will open one.
  p.s. what do you mean by this?

am also proposing that we start using interfaces for grouping collections of functions, which will...

[maxwellmattryan]

Thanks, Nicole!

Rather than nesting modules in modules I think we flatten it slightly and have category folders within the high level folders of a module. i.e. module/interfaces/category/file.interface.ts that way we can categories them into other logical categories than the sub modules and remove the ownership of the file from that module, as it is likely it can be used more globally.

That sounds like a good idea. What do you mean exactly by categories? Would you mind showing what maybe the wallet/ module would look like?

If we categories interfaces into categories we can have one interface per file too, and still keep some organisation.

Yeah I'm down for that. There may be cases where more than 1 have to live in a file perhaps, but this is still an improvement from now!

I am a fan of including the .file-type.ts in the file name. i.e. .interface.

Yes, it's nice because you don't have to visit the file to know exactly what's there. Although I think it should be file.type.ts rather than file-type.ts; I feel like I have seen this convention more.

Need to consider a folder structure for svelte components too. I really like the atomic design principles, and would be good include something like that in our practice.

Sure, I haven't really looked much into this area of Firefly to refactor. If you have any resources about atomic design that you like, I'd love to check them out (currently reading the Adobe one). It seems like this would also help isolate UI logic in more specific components.

This isn't quite related, but another thought I've had is that it might be nice to have an organized way of communicating from Svelte component > TS lib > wallet.rs bindings. Not exactly sure what this would look like, and also not sure if a layered architecture approach is good somehow (although this sounds a bit too heavy to me).

I think the point on naming of wallet / profile etc. needs its own discussion. I will open one.

Sweet 👍

p.s. what do you mean by this?

I meant that if we use interfaces for grouping functions together, then we can import those for whatever is needed by a component. We can also do type substitution, which would be useful at least for transactions of different types or eventually transactions with different types of assets (really rough example):

const signIotaTransaction = (address: string, amount: number): Promise<Transaction> => new Promise(() => ({
    payload: `IOTA::${address}`,
    signature: 'IOTA_TX_SIGNATURE'
}))
const broadcastIotaTransaction = (transaction: Transaction): Promise<Transaction> => new Promise(() => transaction)

const signNftTransaction = (tokenId: string, address: string): Promise<Transaction> => new Promise(() => ({
    payload: `NFT::${tokenId}::${address}`,
    signature: 'NFT_TX_SIGNATURE'
}))
const broadcastNftTransaction = (transaction: Transaction): Promise<Transaction> => new Promise(() => transaction)

// in wallet/types/transaction.type.ts
type Transaction = { payload: string, signature?: string }

// in wallet/interfaces/transactor.interface.ts
interface ITransactor {
    signTransaction: () => Promise<Transaction>
    broadcastTransaction: (transaction: Transaction) => Promise<Transaction>
}

// in wallet/iota.ts
const IotaTransactor = (address: string, amount: number): ITransactor => ({
    signTransaction: () => signIotaTransaction(address, amount),
    broadcastTransaction: (transaction: Transaction) => broadcastIotaTransaction(transaction)
})

// in wallet/nft.ts
const NftTransactor = (tokenId: string, address: string): ITransactor => ({
    signTransaction: () => signNftTransaction(tokenId, address),
    broadcastTransaction: (transaction: Transaction) => broadcastNftTransaction(transaction)
})

// in wallet/transactor.ts
const Transactor = async (transactor: ITransactor): Promise<Transaction> => {
    const signedTransaction = await transactor.signTransaction()
    return transactor.broadcastTransaction(signedTransaction)
}

// in routes/wallet/Send.svelte
let toIotaAddress: string = 'iota1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq'
let amount: number = 10_000_000_000

async function handleOnSendIotaClick() {
    const transaction = await Transactor(IotaTransactor(toIotaAddress, amount))

    // do some logic with transaction
    console.log('IOTA TX: ', transaction)
}

// in routes/digital-assets/Send.svelte (?)
let tokenId: string = 'RANDOM_TOKEN_ID'
let toNftAddress: string = 'iota1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq'

async function handleOnSendNftClick() {
    const transaction = await Transactor(NftTransactor(tokenId, toNftAddress))

    // do some logic with NFT transaction
    console.log('NFT TX: ', transaction)
}

But that may be overdoing things. Perhaps we can do the code reorganization then figure out some better design patterns after that?

[laumair]

• Since with this proposal, we have named directories, do we really need to have the files named as well? For instance, it is quite clear from constants what the files under constants will look like.

I don’t really have a strong opinion about this though. If we agree to have .<file-type>.ts approach, then I would only suggest to also do it for Svelte component files;

• Could we perhaps aggregate enums, interfaces and types ? That will simplify it a little bit imo. If we need to differentiate them, we could use some prefix e.g., IWallet for Wallet interface;
• Do we really want to have store for each module? Wouldn’t it be better to have store as a dedicated module? I am wondering if module level store could lead to circular dependencies?
• In relation to the previous point, we should also define some guidelines for imports within modules. For example, can common module import from other modules?
• I was gonna suggest using barrel import but good that you have already added it :) ;
• Happy with path aliasing — It should also be done for mobile & desktop;
• wallet API methods definitely need a single API for usage. Good that we need to improve it with this refactor;
• I would also suggest to have a short documentation accompanying each module. The easiest way would be to enforce JSDoc and have a markdown file automatically generated;

Very good proposal. I think once we have an agreement from everyone on this, the next step would be to plan how to best approach these changes.

[nicole-obrien]

Could we perhaps aggregate enums, interfaces and types ? That will simplify it a little bit imo. If we need to differentiate them, we could use some prefix e.g., IWallet for Wallet interface;

I don't like grouping enums with interfaces and types, they feel more closer to constants.
Don't google should you prefix Typescript interfaces with I, it is a rabbit hole; I prefer the I though.

Do we really want to have store for each module? Wouldn’t it be better to have store as a dedicated module? I am wondering if module level store could lead to circular dependencies?

Is to do with ownership, if we wanted to remove a module/sub-module we could just delete everything in one place, with the opportunity to use the stores from parent modules?..

In relation to the previous point, we should also define some guidelines for imports within modules. For example, can common module import from other modules?

Good question, does it makes sense that other modules can import from common but not the other way?

[maxwellmattryan]

Since with this proposal, we have named directories, do we really need to have the files named as well? For instance, it is quite clear from constants what the files under constants will look like.

Yes, I agree 😅 'tis a little redundant.

Could we perhaps aggregate enums, interfaces and types ? That will simplify it a little bit imo. If we need to differentiate them, we could use some prefix e.g., IWallet for Wallet interface;

I tend to think of enums closer to types as well, but I think we should separate them. At the very least it's worth separating interfaces because we are using them to define all types; I think we should be using them mainly for groups of functions like the wallet api object and use type for data structures.

In relation to the previous point, we should also define some guidelines for imports within modules. For example, can common module import from other modules?

I wrote some rules in the proposal, but these may need be to be adjusted... what do you think?

CAUTION: Please take note of the following:

• Modules or source files in core must NOT depend on anything unless it is also in core.
• Modules or source files in common must NOT depend on any <feature> modules; only core.
• Modules or source files in <feature> modules must NOT depend on any other <feature> modules; only common, core, or the same module

[maxwellmattryan]

[WIP]

Firefly Refactor Integration

There needs to be a plan going forward in integrating this refactor into the existing repository as it is quite substantial. There are all sorts of ways to organize this work, parallelizing and serializing some tasks in a certain configuration, so if you have any thoughts please let it be known 🙂

Some Things

It would be nice to apply some things in general when doing the refactor to help clean the code. I believe for some of these there may be tools to enforce them (if we all like them and agree 👍) to make it easier, but anyways.

• Although not necessary, it would help us if at the same time we write tests according to a rough list of coverage requirements. This list doesn't take the modified directory structure into account, although most of the functions are listed that need to be tested anyways. If you feel that something has too high or low of a priority for test coverage then let's figure something out.
• Having a specific order for our imports within TS and Svelte files, with logical sections separated by line. Many things are going to change with how we do imports (path aliases, barrel imports), so I think also applying a certain order would clean them up nicely. It's also duly important that it's simple and easy for the developers to remember.
  I think using the order of svelte > third-party > iota-libs > shared/lib/typings > shared/lib > local or relative imports makes sense as I think developers are more likely to to modify first function then type imports. Additionally we should apply an alphabetical order for each of those groupings by the import itself, and also order the imported functions, objects, etc. This is shared/lib/migration.ts before and after:

  import { addEntry, finalizeBundle } from '@iota/bundle'
  import { tritsToTrytes, trytesToTrits, valueToTrits } from '@iota/converter'
  import { TRANSACTION_LENGTH } from '@iota/transaction'
  import { asTransactionObject } from '@iota/transaction-converter'
  import { closePopup, openPopup } from 'shared/lib/popup'
  import { activeProfile, updateProfile } from 'shared/lib/profile'
  import { appRoute, walletSetupType } from 'shared/lib/router'
  import type { Address } from 'shared/lib/typings/address'
  import type {
      AddressInput,
      Bundle,
      HardwareIndexes,
      Input,
      MigrationAddress,
      MigrationBundle,
      MigrationData,
      MigrationLog,
      MigrationState,
      SendMigrationBundleResponse,
      Transfer,
  } from 'shared/lib/typings/migration'
  import { AppRoute, SetupType } from 'shared/lib/typings/routes'
  import Validator from 'shared/lib/validator'
  import { api } from 'shared/lib/wallet'
  import { derived, get, writable } from 'svelte/store'
  import { localize } from './i18n'
  import { showAppNotification } from './notifications'
  import { LedgerMigrationProgress } from 'shared/lib/typings/migration'

  import { derived, get, writable } from 'svelte/store'
  
  import { addEntry, finalizeBundle } from '@iota/bundle'
  import { tritsToTrytes, trytesToTrits, valueToTrits } from '@iota/converter'
  import { TRANSACTION_LENGTH } from '@iota/transaction'
  import { asTransactionObject } from '@iota/transaction-converter'
  
  import type { Address } from 'shared/lib/typings/address'
  import {
      AddressInput,
      Bundle,
      HardwareIndexes,
      Input,
      LedgerMigrationProgress,
      MigrationAddress,
      MigrationBundle,
      MigrationData,
      MigrationLog,
      MigrationState,
      SendMigrationBundleResponse,
      Transfer,
  } from 'shared/lib/typings/migration'
  import { AppRoute, SetupType } from 'shared/lib/typings/routes'
  
  import { localize } from 'shared/lib/i18n'
  import { showAppNotification } from 'shared/lib/notifications'
  import { closePopup, openPopup } from 'shared/lib/popup'
  import { activeProfile, updateProfile } from 'shared/lib/profile'
  import { appRoute, walletSetupType } from 'shared/lib/router'
  import Validator from 'shared/lib/validator'
  import { api } from 'shared/lib/wallet'

The Plan

It is best if this refactor is split into both logical and manageable phases for us so we can get it done efficiently.

TODO

Phase 01 - core functionality

I think it makes most sense to start the refactor around the central functionality of the app.

TODO

[begonaalvarezd]

Just a small comment about:

Having a specific order for our imports within TS and Svelte files

For this I tend to like using the VSCode Organize imports shortcut (Shift+Alt+O), its very easy, automatic, and it will format the imports in the same order for everybody (or it should). It also sorts them alphabetically.

[nicole-obrien]

I can second that, having some arbitrary order will not last long and hard to enforce. Best to just do the shortcut in VS code. Can we add this to yarn format too?

[maxwellmattryan]

@begonaalvarezd:

For this I tend to like using the VSCode Organize imports shortcut (Shift+Alt+O), its very easy, automatic, and it will format the imports in the same order for everybody (or it should). It also sorts them alphabetically.

Nice. I like to use JetBrain's WebStorm app, but I'm sure there's a similar feature for this. It'd be nice to be able to define a custom import order in a file or something somewhere that is used by the IDE when we auto-import stuff.

@nicole-obrien:

Can we add this to yarn format too?

It looks like it; gonna put a link here to ESLint sort-imports rule.

[begonaalvarezd]

yup best would be adding the rules to the repo so we all format in the same way 👌🏼

[maxwellmattryan]

I have started writing a finalized proposal for this refactor here (HackMD).