node-eth / node-eth-packages Goto Github PK

Rebuild.sh

It would maybe be useful if the user could pick whether or not he wants to see the logs, or we could store the logs somewhere. The logs helped me numerous times because the project is still unstructured and there is a lot of moving parts. Lets maybe add an option to show the logs if --logs / -l flag is provided

PushSDK that we are utilizing proved itself a bit weird, it has several issues with it. I've been following the chats and people had complained about it. So far i have experienced:

1. Function Deprecation errors and logs (it is totally fine, i could build a workaround)
2. CommonJS and ES Modules conflicts and errors in the @pushprotocol/restapi package
3. @pushprotocol/restapi also had some kind of assertion errors

I found a quick solution to it by downgrading the packages to the following:
@pushprotocol/restapi: 0.0.4
ethers: 5.6.x - look at the image below this answer

I would say that we stick to these versions until i figure it out with push sdk devs whats going on (I will link the issue i open on pushSDK's gh repo here, once i open it)

Currently, the rebuild.sh script in the ./scripts/ folder is not being invoked once nodemon notices the changes

This issue is in correlation to the #9 - Rebuild script

The idea is that, when developing:
watcher/development script is initiated -> nodemon picks up the changes in js/html -> fires off the rebuild script

We should make sure that the local nodeRED installation is not getting pruned on every rebuild too. That should be completed with @benlazzero 's latest commit to the scripts folder - https://github.com/node-eth/node-eth-packages/commit/22bdff271d6f19cf39c1ff69352f69ea5ec68339

This is currently not working, rebuild must be initiated manually. It is not that resource intensive, although it can be PITA sometimes cus you may lose some nodes if you didnt deploy them before refreshing the nodeRED UI on 1880

Push protocol is a great tool but the thing is it has a lot of methods/functions with similar names

subscribe & unsubscribe look pretty similar when you skim over them and when you have a lot of stuff on your mind

I've come to the point where i have methods such as:
unsubscribeFromChannel and subscribeToChannel and you might argue that it is a bad naming convention and i do share some opinions on that. Visually they are hard to distinguish when working.

I would say that a temporary solution would be method aliasing in the main ./lib/PushService.js with proper and quite visible documentation, such as alias of subscribeToChannel could be optIn, vice versa optOut

This could be a temporary solution until we refactor the class and break it down into smaller pieces that are user / channel / specific-field-oriented