🏗 Firefly Shared Library Refactor - Overview

# 🏗 Firefly Shared Library Refactor - Overview ###### last updated: 02/02/2022 ###### tags: `iota` `firefly` `documentation` ## Summary This document details an overview to what is a substantial refactor to one of Firefly's components - the shared library of functions used in both desktop and mobile (the extension __does NOT__ use these functions but rather calls `wallet.rs` by different means). ## Motivation While Firefly continues to grow and accommodate more functionality, platforms, and so on, it is important to keep our source code organized in aiming to achieve... - a quick understanding of what code what will or should be in which file - ease of navigating through directories of source code and source code files themselves (i.e. more hierarchy, smaller files) - an improved understanding of how Firefly is designed and architected - ease of reading, writing, and adjusting unit (and integration) tests - more standardization and consistency in the ways we structure and write our code (e.g. how should functions be used / accessed, how should errors be handled, how we wrap the underlying `wallet.rs` API, and so on) - a more composable, consumable library of functions __that we can potentially publish__ It is worth noting that an ultimate goal of this refactor is to increase developer efficiency and accessibility within the Firefly ecosystem. ## Details This refactor involves four types of changes: 1. Breaking up source code files where... - it makes logical sense to group specific functions within a file into their own respective file - there are simply too many lines of code, making it hard to consume or modify a file 2. Organizing collections of source code files into [modules](https://www.typescriptlang.org/docs/handbook/modules.html) 3. Resolving broken import paths for other library files, UI components, and so on as a result of the first two types of changes 4. General code adjustments according to new code conventions (defined [here](https://hackmd.io/FpiM5-uWSGavKfFY89omxw?view#Modules) in phase no. 1) ### Phases Due to the size, scope, and complexity of this refactor, it is best implemented in incremental phases. This allows us to... - maintain the highest degree of stability possible while making significant changes - structure the changes so that disruptions to out-of-scope code happens at once - more easily identify points of error along the way There will be a total of __two__ phases: - [WIP] [Phase No. 1](https://hackmd.io/FpiM5-uWSGavKfFY89omxw) - support for changes in phase no. 2 - [WIP] [Phase No. 2](https://hackmd.io/4VBXE7u7RyeD9kgjPV3tgQ) - the actual changes for outlined and setup in phase no. 1 ### Pull Requests and Branches This refactor uses the following Git branch naming conventions: - `refactor/shared/lib/p<num>` - branch for a particular phase - `refactor/shared/lib/p<num>-task-name` - branch for a task of a particular phase ## Notes _None_