Refactoring

[iwuvjhdva]

Estimation from #113:

Refactoring estimation

• 2H Prepare code style guidelines
• 4H Refactor CSS #58
• components:
   ◦ 2H address-book:
      ◦ rewrite with map and simpler actions
      ◦ use address-book service only for config caching
   ◦ 2H overview:
      ◦ rename Balance to balance
      ◦ if → switch
      ◦ uniform list component
      ◦ popup menu
      ◦ CSS
   ◦ 1H own-addresses:
      ◦ uniform list component
   ◦ 4H send-cash:
      ◦ Reduce actions number and chaining
      ◦ Remove the ugly checkPrivateTransactionRule() and handleAddressUpdate(), change view logic instead of changing the state
      ◦ Integrate proper form validation (a 3rd party package supporting schemas, error messages etc), remove the related codefrom the epic
      ◦ CSS
   ◦ 4H settings:
      ◦ Integrate proper form validation (see above)
      ◦ Move child process logic to a separate component
      ◦ Move auth logic to a separate component
   ◦ 2H system-info:
      ◦ Move operations logic to a separate component
      ◦ Move getInfo() to status-modal #96

Total: 21H

[iwuvjhdva]

VERY EARLY DRAFT of the code style guidelines, just for it to be somewhere:

• NO CODE DUPLICATES!!!
   ◦ Read about DRY principles, take a course on PluralSight.
   ◦ If you copy and paste anything in the code - that is an alarm that you’re doing something wrong!
   ◦ (After the PoC) Write tests. If the task doesn’t have tests that are fully covering it then it’s not considered as complete
• if → switch
• force curly braces for if statements
• lowercase names for files
• use Redux store only for cross-component actions and state sharing, use component’s state in the rest of the cases
• Simple is better than complex - avoid using complex logic like actions chaining and spaghetti observers streams when possible
• create a service only if it’s really neaded, logger-service, clipboard-service, dialog-service are the bad examples
• remove eventConfirm() and dispatchAction() from everywhere, please
• separate view from controller, for example, the display message “confirmed” = “Yes” or “No” should be created in overview.js, not in rpc-service!!!
• error handling:
   ◦ display toastr messages only in the epics or views, services only return clean errors messages
   ◦ create only clean error messages: “The wallet is warming up” instead of “Error occurred: The wallet is warming up” - “Error occurred” should be added in the view on toastr call
• use batch RPC transactions whereever possible, the node supports only 4 simultaneous connections by default!
• split a function into a smaller functions:
   ◦ if a function is more than one screen long - THAT’S NOT OKAY, having a
   ◦ having a function 3 lines long IS OKAY
• use ES6’s private methods with this::<methodName>()
• don’t use strings (like ‘ok’) for checking if a function result is good, use Booleans or enums
• don’t leave garbage comments:
   ◦ large (>1 line) code blocks commented out, those can be recovered from the SCM if needed
   ◦ personal notes that you made at the implementation phase
• consider switching to TypeScript, it helps keeping the codebase cleaner

[iwuvjhdva]

+Move Tool Bar Buttons actions from NaviBar