Refactoring and cleaning

Now that Specter is quite stable, there are many parts of the code which could use some refactoring. I’ll list here the points which I’m already aware of and will continue to add based on comments here/ other things I notice.

• Remove nwjs - this was an old experiment that is not used anymore). - (#135)
• Break down logic.py into smaller files - this file has grown pretty huge and could be broken down into its composing classes - which would make it more readable and organized. - (#160)
• Make reusable UI components - We currently have a lot of duplicated code in the front end, which we could turn into Jinja macros/ Custom elements - (#136).
• Refactor frontend - In addition to using components, there is much old code that could be removed/ rewritten more nicely - (#136).
• Refactor logic classes - Currently, these classes (WalletManager, DeviceManager, Wallet, Device) are somewhat unstructured, the managers aren’t exactly a list nor an object, and the wallet contains some unnecessary data and uses a _dict instead of properly defining its attributes. We could refactor these classes to be better specified, more readable, and optimized. - (#160)
• Connect wallet class with the devices - Currently, a wallet is completely separated from the devices it uses. For example, when deleting a device, the wallet will still remain. We should connect them and make them “aware” of each other. - (#160)
• Refactor HWI - The current code we use for HWI is somewhat messy and requires unnecessary extra steps from the user. This refactoring is part of #131. (#143)
• Structure Files - Files today (both front and back end) are somewhat disorganized, we could probably structure them better into directories in a way easier to reason about and navigate - (frontend: #136, backend: #160).
• Remove Vue - We barely use Vue in the frontend, and where we do it’s not hard to replace it with Jinja + JS. We should probably consider removing it, as it doesn’t make sense to have it if we barely use it - (#136, #141).
• Improve error handling - We use a lot of try/catch through the codebase, but in many points we just return None or print something or just pass. We should refactor those parts to send the user a proper error message/ page (maybe with an option to copy/ report the logs). - (#139, #156, #160)
• More testing - Currently our tests for Specter are quite scanty, we should probably add much more coverage of the code.

Please comment below with everything I should add to the list.

(Update: Note that I edit this as stuff change.)

[stepansnigirev]

I think it would be also nice to split the settings screen, now it is pretty large already. We can do a top menu similar to wallet screens with different submenus:

• Bitcoin Core
• Authentication
• HWI bridge
• Miscellanous

Then in multi-user case Bitcoin Core config would be unavailable for normal users, and admin could manage users in the Authentication section.

[stepansnigirev]

I was experimenting over the weekend with hwibridge, and I found a few interesting ways how we can refactor our codebase.

Custom elements

Custom elements look pretty interesting. They are supported by all major browsers (maybe except Edge), and all the code is nicely isolated from everything else. They don’t require any web framework, so we could get rid of vue with them. Here, for example, a QRcode component ported from vue component that @gorazdko made to custom elements: https://github.com/stepansnigirev/hwibridge/blob/master/src/templates/components/qrcode.html

Then, to use it we only need to make sure that qrcode.html is included in jinja template, and use <qr-code value="blah"></qr-code> component wherever we need it. It also works fine with vue or vanilla javascript - it has observers that properly changes the element when content is changed.

JSON-RPC for JS API

Another thing I tried is on the backed side. I made HWI API in JSON-RPC format, this means that all javascript code related to HWI would need to access only a single endpoint, and I think it’s pretty convenient. It also allows isolation of the HWIBridge component to a single class, that doesn’t even need to know anything about flask and our webapp, and in flask we only pass through the requests to the class. When we want to extend functionality of the class we just introduce new methods there and in the javascript, no need to touch the server itself. Here is the route for /hwi endpoint: https://github.com/stepansnigirev/hwibridge/blob/master/src/server.py#L23-L30 Here is the HWIBridge class implementation and JSONRPC parent class: https://github.com/stepansnigirev/hwibridge/blob/master/src/hwibridge/logic.py#L63

What do you guys feel about that? Does it make sense to use this structure? Anything that can be changed or improved?