# Tag Info

5

A few thoughts; Most would write const flatFeature = []; to initialize an array in javascript, though what you have is certainly correct. You should strive to de-nest your code. Having code unnecessarily placed in if or if-else blocks increases the number of paths through your code, making it harder to follow and unit test. In this case, you could de-nest ...

4

You can override the executor and can pass an onCancel function to it like following: class ResponsePromise extends Promise { constructor(executor) { const onCancel = (cb) => { //using nextTick because we cant use "this" before super() setTimeout(()=> { this.cancelCb = cb; }) } const oExecutor = (...

4

Comments While the code is mostly simple to follow, it would be good to add comments to document what decisions you made. Even if you are the only one maintaining this code your future self might not remember what considerations you had in the past. At least document the input, output and purpose of functions. Some style guides call for comments to be in ...

3

Be aware that mixing await statements with .then()/.catch() statements can be a Code Smell, indicating an incomplete understanding of how Promises and async/await work. That said, there are times/places for mixing these constructs but you need to be careful when doing so. It's generally better to prefer one or the other (with async/await usually being the ...

3

Some thoughts: You are using async but not "using" it. You can simplify this code for the reader by doing const accessToken = await axios.post(...); and similar to de-nest and make the code more understandable. This also helps your avoid bad variable names like res1, res2, res3, etc. Promise.all() is your friend when it comes to making batch ...

3

I am not primarily a JS developer, therefore I won't assist you with the JavaScript part itself, but I can give you a few hints regarding several issues I've found. Lack of transactional safety In your example, you're executing two DELETE statements on the database. 1) delete t1, t2 from postschema t1 join commentschema t2 on t1.id = t2.postid where t1.id = ?...

3

The use of arrow functions looks okay to me. One advantage to using them is that they can be simplified to a single line but one might hold the opinion that is less readable. For example: app.get('/welcome', (req, res) => { res.render('pages/welcome'); }); Could be simplified to: app.get('/welcome', (req, res) => res.render('pages/welcome')); Note ...

2

Consider using a hashmap of provider -> process. This will enable you to register new providers with relative ease. async function githubRelease({user, repo, part = ""}) { let json = (await (await fetch(https://api.github.com/repos/${user}/${repo}/releases/latest)).json()) if (json.message === "Not Found") throw "Invalid ...

1

Discovered this needs rework Testing this with small numbers shows that for all practical purposes, this function is broken. I'd like roundupDiscount(Number.EPSILON) to be 0 (which could come about from subtracting two numbers meant to be equal, but differing by an error (similar to the classic (0.1 + 0.2) - 0.3)). However for a number like Number.EPSILON ...

1

Now that you've allowed the users to add custom providers, how about hiding the providerMethods object itself, and only providing a function which allows them to add to it. This would allow you to also validate if the users' want to override behaviour for predefined providers. You have a process.exit(1) inside the call to usage(). Butm when used from cli, ...

Only top voted, non community-wiki answers of a minimum length are eligible