Redesign current architecture

[zabawaba99]

Based off #18

---

It feels a bit odd having to pass something down from main, to the builder to a vow and then to a promise just to have verbose output.

[Tonkpils]

@zabawaba99 I figured we have this issue here we can talk about the design here and use this. I've created a branch to get started on the work. Once we have something discussed here we can add changes and make a PR to track those changes

[zabawaba99]

From the brief discussion we had I put together an extremely rough sketch of the redesign might look like.

Overview

The concept would revolve around having an object that allows us to exchange messages between components (labeled Exchange in the image above). All components would register with the exchange and tell it what events it expects.

Exchange

The purpose of the exchange is to accept messages and route them to the appropriate consumer.

File System Watcher

This component is in charge of watching the file system. Whenever a file is modified, it will send a message through the exchange to notify that the tasks should be run.

Messages Sent

• "rebuild"

Messages Received

• n/a

Task Executor

This component is in charge of running the build/run steps in the snag file. It will register itself against the exchange and listen for a message telling it to rebuild. While building 3 events will be emitted per command that is ran. The exchange will be notified when a command is about to start, is in progress and is finished.

Messages Sent

• "cmd_starting" "<cmd_details>"
• "cmd_running" "<cmd_details>"
• "cmd_finished" "<cmd_details>"

Messages Received

• "rebuild"

UI

This component is in charge of building and managing the terminal ui. It will register against the exchange and listen for messages telling it about the status of the processes running.

Messages Sent

• n/a

Messages Received

• "cmd_starting" "<cmd_details>"
• "cmd_running" "<cmd_details>"
• "cmd_finished" "<cmd_details>"

[zabawaba99]

And alternative to the exchange would be to abstract components into interfaces something like:

(I got a little lazy with the drawing 👯 )

Where the top level are the interfaces and the lower level are implementations of said interface. This would allow us to create a Notifier with a Runner interface. Whenever the Notifier deems that a new build should run it would call a method on the running, perhaps something like runner.Run().

This design would also allow us to plug and play components and keep the code modularized and clean. We can get into a bit more detail regarding this design if we choose to go with this one over the exchange.

[Tonkpils]

Changes can be followed on https://github.com/Tonkpils/snag/tree/decouple