Live data from Hacker News

Node v8.1.2

nodejs.org

31–40 of 49 posts

Re: Node v8.1.2

#31
post #29
post #21

Earlier quoted context omitted.

I understand the reasons why async/await is designed the way it is, but I still think it is backwards. Really if you wanted to truly make async programming approachable, you should make it transparent. What I mean by this is that instead of marking a function as async, and awaiting values, you'd mark lines as async, opting out of implicit awaits. I wrote up some thoughts on this here: https://github.com/utilise/emitt…

Agreed. Async is like a virus. Once you start somewhere pretty much everything else must be async too. In C# you can call async code from not async code and then call Task.Wait. Not sure if JS can do that. But it still beats promises or callback hell.....

You can't really transition between async and sync scopes, no.

Re: Node v8.1.2

#32
post #27

Earlier quoted context omitted.

This is my tsconfig.server.json: { "files": [], "compilerOptions": { "baseUrl": ".", "moduleResolution": "node", "target": "es2017", "jsx": "react", "experimentalDecorators": true, "sourceMap": true, "skipDefaultLibCheck": true, "lib": [ "es2017", "dom" ], "allowJs": false, "paths": { "*": [ "./ClientApp/types/*", "*" ] } }, "exclude": [ "bin", "obj", "node_modules" ] } edit: remove unneeded entries

Looking at "paths", shouldn't those @types (history, redux & react) be picked up automatically, at least as of TypeScript 2.0? Also: "*": [ "./ClientApp/types/*", "*" ] I like that. I may have to add it to my app and get rid of our typings.d.ts (currently included through "files") once and for all.

They were there to fix "Duplicate identifier" errors caused by multiple dependencies fetching their own copies of type definitions.

But you are right: typescript or those dependencies have improved and they are no longer necessary. I removed them and everything still works.

Re: Node v8.1.2

#33
post #13
post #4

Earlier quoted context omitted.

Aync/await is the best thing since sliced bread. It has made my life so much easier.

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

It IS promises ;) labeling a function as async makes it return a promise. await is sugar for avoiding having to roll your own promise tree.

Re: Node v8.1.2

#34
post #13
post #4

Earlier quoted context omitted.

Aync/await is the best thing since sliced bread. It has made my life so much easier.

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

Sounds interesting -- do you have any resources handy that cover what you allude to (spec. comparing async calls to promises, and favoring the latter?) I use both in my ui code and they seem to have their niche for me. I prefer promise based calls when I want to separate out fetching data from the state-mutating callback, or when I may want to "cancel" something (ex: fetch a list of items for a list component, then unmount the component before the list returns -- no need to handle the response data anymore).

Re: Node v8.1.2

#35
post #29
post #21

Earlier quoted context omitted.

I understand the reasons why async/await is designed the way it is, but I still think it is backwards. Really if you wanted to truly make async programming approachable, you should make it transparent. What I mean by this is that instead of marking a function as async, and awaiting values, you'd mark lines as async, opting out of implicit awaits. I wrote up some thoughts on this here: https://github.com/utilise/emitt…

Agreed. Async is like a virus. Once you start somewhere pretty much everything else must be async too. In C# you can call async code from not async code and then call Task.Wait. Not sure if JS can do that. But it still beats promises or callback hell.....

A better term than virus is that async is a monad. Welcome to programming with monads. ;)

JS async produces Promises like C# produces Task, so you can call an async function and use the result as a Promise.

Re: Node v8.1.2

#36
post #30

Earlier quoted context omitted.

Definitely something to the addage "if it ain't broke don't fix it". Some of our less critical modules are set to latest others are updated with care. Our modules are not under source control so are refreshed on deployment. We use Snyk to monitor for vulnerabilities, works pretty well.

Are you at least checking in your npm-shrinkwrap.json? (If not you've got pain waiting to happen, that you won't find out about until deploy time)!

This so much - shrinkwrap before it bites you when a CI kicks off a deploy that fails because it pulled latest minor dep release that broke everything (happened even in big lib like Angular 2 for us after stable 2.2 !) while your local box is running fine with a cached older version.

Re: Node v8.1.2

#37
post #30

Earlier quoted context omitted.

Definitely something to the addage "if it ain't broke don't fix it". Some of our less critical modules are set to latest others are updated with care. Our modules are not under source control so are refreshed on deployment. We use Snyk to monitor for vulnerabilities, works pretty well.

Are you at least checking in your npm-shrinkwrap.json? (If not you've got pain waiting to happen, that you won't find out about until deploy time)!

Yes. I've had an app break due to a dependency's dependency update. Was the night before a big product launch. Learned to rely on npm-shrinkwrap the hard way.

Re: Node v8.1.2

#38

Earlier quoted context omitted.

npm outdated -l

But in addition to that, how do you "update all and bump relevant package.json entries, dependencies _and_ devDependencies as appropriate " ? `npm update --save` or `npm update --save-dev` say explicitly "save updates to `dependencies` resp. `devDependencies`" , which causes duplication between dependencies and devDependencies. (Say you have a dep foo and a devDep bar and both are outdated: `npm update --save` will b…

I use npm-check-updates[1] which will update the package.json file with the latest versions of each dependency.

[1] https://www.npmjs.com/package/npm-check-updates

Re: Node v8.1.2

#39
post #29

Earlier quoted context omitted.

Agreed. Async is like a virus. Once you start somewhere pretty much everything else must be async too. In C# you can call async code from not async code and then call Task.Wait. Not sure if JS can do that. But it still beats promises or callback hell.....

A better term than virus is that async is a monad. Welcome to programming with monads. ;) JS async produces Promises like C# produces Task, so you can call an async function and use the result as a Promise.

Can you wait for a promise synchronously? I am pretty new to JS so please forgive if this is a stupid question.

Re: Node v8.1.2

#40
post #13
post #4

Earlier quoted context omitted.

Aync/await is the best thing since sliced bread. It has made my life so much easier.

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

There is no difference, async/await is just another promise notation.
Post reply on HN