-
Notifications
You must be signed in to change notification settings - Fork 1
App refactoring
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 ofgit-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 withgit-assist
without the weird interaction witheasy-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 theAPI
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.