Log events

[baruchiro]

Using the EventEmitter, I'm printing the events to the UI, to see the process and errors if any.

It's very hard to work with the current EventEmitter design. You have to declare manually all the EventNames, and you don't have type-checking for that.
You can achieve type-checking, of course, but it creates a very complicated code.
I think we need to define the events as classes instead of interfaces, and yes, it will be noises in the backend, so maybe create a helper method to create these objects.

Anyway, don't know. We need more helper methods here.

[brafdlog]

This doesn't ever change. Don't think this was what you intended.
Need to add back the logic that updates according to result of scraping

[brafdlog]

In general I think we should replace succeeded and in progress with a single status. Something like:
status: NOT_STARTED | IN_PROGRESS | SUCCESS | FAILURE

Then colors becomes STATUS_COLORS: Record<ScrapingStatus, string | null>

[brafdlog]

You can actually use the event emitter for setting the status instead of awaiting the promise (not a must):

eventPublisher.on(EventNames.IMPORT_PROCESS_START, () => {
// IN_PROGRESS
});

eventPublisher.on(EventNames.IMPORT_PROCESS_END, () => {
// SUCCESS
});

eventPublisher.on(EventNames.GENERAL_ERROR, () => {
// ERROR
});

[baruchiro]

In general I think we should replace succeeded and in progress with a single status. Something like:
status: NOT_STARTED | IN_PROGRESS | SUCCESS | FAILURE

Then colors becomes STATUS_COLORS: Record<ScrapingStatus, string | null>

I think I don't understand... You just suggesting to change the unknown | success | fail with these NOT_STARTED | IN_PROGRESS | SUCCESS | FAILURE?

[baruchiro]

You can actually use the event emitter for setting the status instead of awaiting the promise (not a must):

eventPublisher.on(EventNames.IMPORT_PROCESS_START, () => {
// IN_PROGRESS
});

eventPublisher.on(EventNames.IMPORT_PROCESS_END, () => {
// SUCCESS
});

eventPublisher.on(EventNames.GENERAL_ERROR, () => {
// ERROR
});

As I said before, I don't like to use EventEmitter as a "serial" flow, because I think it is less readable.

[brafdlog]

Discussed on the phone. Easier to communicate that way 🙂

[baruchiro]

I did it. I started with enum but I think for now we can just use the keyof typeof statusToColor

[brafdlog]

Using the EventEmitter, I'm printing the events to the UI, to see the process and errors if any.

It's very hard to work with the current EventEmitter design. You have to declare manually all the EventNames, and you don't have type-checking for that.
You can achieve type-checking, of course, but it creates a very complicated code.
I think we need to define the events as classes instead of interfaces, and yes, it will be noises in the backend, so maybe create a helper method to create these objects.

Anyway, don't know. We need more helper methods here.

I don't fully understand what you mean. You could either listen with onAny if the use case is very generic (as it is in the current implementation of the logger). In this case (as an any generic code) you can only assume that the type is BudgetTrackingEvent which doesn't give you much, but you are listening on everything. Alternatively if your use case is more specific (which I think will happen in the next iterations of implementing the progress indication) you can listen for specific events and get them fully typed.

I am not saying this implementation is optimal, I am just not sure what are the actual pain points so we can improve the current design. We can discuss this on the phone if you want.

[baruchiro]

I can't tell you exactly what is the pain. Of course, I can listen to a specific event to get the specific type. But I want it to be generic.

Also, take the message as an example- I expect all the events to have a message generated by the other event fields, I think if we will use classes, we can create the message as a function.

In short, I think the better is to let you try to improve my code, if you want and if you have time, and see if it hurts you.

[brafdlog]

I can't tell you exactly what is the pain. Of course, I can listen to a specific event to get the specific type. But I want it to be generic.

Also, take the message as an example- I expect all the events to have a message generated by the other event fields, I think if we will use classes, we can create the message as a function.

In short, I think the better is to let you try to improve my code, if you want and if you have time, and see if it hurts you.

Thats fine. As I said we will have a real use case once we implement the progress indication. For now I suggest just the changes in the comments

[baruchiro]

@brafdlog Ready, waiting for your approval.