mixmaxhq
Refactors code to support inheritance
At present everywhere there are checks for whether the queue is bull or not based on which the functionalities differ.
In this PR, this task have been properly handled by using classes and inheritance where by which all the bee related logic goes in bee.js and all the bull related logic in respective bull.js.
If another queue has to be integrated in future, it will be so much easier to just write another implementation which implementation details which affecting the core functionalities of the UI.
This makes the code more concise, easy to understand and extendable without extra if else conditions.
Three classes are mainly used:
- Queue: which holds the actual queue within it and provides a common interface for the application to react on function calls.
- Job: acts as an adapter for jobs for different queue implementation.
- JobData: represents not the actual job object but just the data that can be exposed to UI, JSON or anywhere else.
@skeggse Just wanted to confirm why have return void res.**json type changes have been added?
@skeggse A thorough testing is still required, I did testing with just bull queue of some of the basic functionalities that I was using. I thought to first get a review done before we can move onto complete testing again together.
There should not be any potential risks associated as such, in this code refactor I carefully converted all the if and else statements to different classes. Not sure if I understood your statement here correctly.