Is there some security reasons?
I'm not exactly sure. I'm pretty certain you could easily just do
const hashNode = val => Promise.resolve(crypto
.createHash('sha256')
.update(val)
.digest('hex')
)
@Chalarangelo is there a reason that's done?
That's one of the oldest snippets, I think we kind of adapted this from some StackOverflow answer, so that's why it looks that way. If the way it works and its use cases are not altered, we should update it to this new version.
IMO. Promise is unnecessary here also.
Two reasons why we are using a promise here:
I am pretty sure we should stick to this returning a promise, just clean up the code a bit. Plus, it's gonna be a breaking change and this is quite a popular snippet in my experience.
@Chalarangelo this is a blocking stream, wrapping it in a promise merely delays when you can use it, which would mean that it actually works as finish hash, update hash, next available loop return hash.
Although I think this answers why we put it on next tick. By putting it on next tick we offload it until the event loop is free, which since these algorithms can be heavy would in fact be preferred than randomly running a blocking hash out of nowhere.
@cncolder Looks like we remembered why it's done next tick. It's to prevent a long blocking operation and use the event loop to allow for other operations to finish being queued instead of delayed in case of a large hashing operation(everything that gets added after will be delayed though)
My suggestion is that hashNode is updated to explain why it uses the setTimeout so as to put it onto the event loop and not block
@skatcat31 My thoughts exactly. Could you PR an update for the explanation, just so we remember why this is done like this next time? 馃槢
Sure. When I get home tomorrow I'll issue the pr
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.