Skip to content
This repository has been archived by the owner on Feb 19, 2024. It is now read-only.

App refactoring

Alexis Lemaire edited this page May 7, 2020 · 1 revision

Keeping here a record of the planned refactoring for git-assist instead of having it in an hanging issue.

Copied from #68

For now prompting and processing of user inputs are kind of coupled together. They are separated in files but brought together in index.js file which are entry points for utilities and the overall approach looks too monolithic as is (purely thought to work as a CLI tool and using the processing part of the CLI tool requires to know where is stored the utility we want, like done for reusing pull.js in the auto-pull.js).

Now that the app expanded beyond its initial scope, should split the processing logic into an API and the prompting logic into CLI (for example, can be named differently).

Advantages:

  • CLI modules will be responsible only for interacting with user via console. This is pretty much the UI of the CLI version of git-assist
  • API modules are the one in charge of processing. They do the heavy lifting.
  • allows for different UIs. For example: this will make it easier to develop the future Electron app so that non-developer can work easily with git-assist without the weird interaction with easy-use scripts
  • makes testing easier as well since we can independently test CLI (correct prompting flow), API (good processing) but also do integration testing of the whole CLI tool (prompting + processing)
  • in the long term, having those separated means we can also publish the different UIs separately and then install the processing unit to build a fully fleshed tool (for example the CLI tool combines the CLI UI and the API for processing)

Draft:

For now there is one repository which contains all the code for the CLI application. The idea is to decompose all this into multiple repositories (name are subject to change):

  • @git-assist/cli-ui: in charge of user prompting via console. Offers probably some kind of class exported. Asks user for input and return the answer that can be used downstream. Having a class approach can allow later on to implement some kind of local config for different display for example
  • @git-assist/processing-unit: in charge of GitHub related tasks. Same idea with the class as @git-assist/cli-ui.
  • @git-assist/cli: this is the CLI app that has @git-assist/cli-ui and @git-assist/processing-unit as dependencies. Basically pipe @git-assist/cli-ui output into @git-assist/processing-unit input to provide a CLI UI in front of the processing core
  • @git-assist/app: this is the Electron app. It has @git-assist/processing-unit as dependency and work with its own frontend to provide inputs to inject and process into this dependency

@git-assist/processing-unit should run before any other methods the sync-config and ssh-auth (soon available in master) utilities. This simplifies the code as we don't need to call those utilities inside of every methods.

Both @git-assist/cli-ui & @git-assist/processing-unit will contain the default/base utilities for git-assist. Can have some kind of add/remove method that could append/remove extra utilities into those modules so that people can develop their own solutions if they want to.

Clone this wiki locally