Live data from Hacker News

Show HN: Nothing.js – A chainable mock object which always returns itself

github.com

31–40 of 43 posts

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#32

I think this kind of access pattern is typically a code smell. Instead of carrying around arbitrarily nested values you should try to normalize it into a known and consistent shape when crossing serialization boundaries. Proxy pays a big performance penalty, and I doubt it'll be improving any time soon. In addition, I believe it's not possible to polyfill Proxy. An alternative could be to just wrap the deep property…

[deleted]

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#33

I think this kind of access pattern is typically a code smell. Instead of carrying around arbitrarily nested values you should try to normalize it into a known and consistent shape when crossing serialization boundaries. Proxy pays a big performance penalty, and I doubt it'll be improving any time soon. In addition, I believe it's not possible to polyfill Proxy. An alternative could be to just wrap the deep property…

Yeah, my first thought when seeing that it uses Symbol and Proxy was that Proxy can't be polyfilled. But it looks like there's partial polyfills for it: https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#34

One thing I've been finding increasingly while using Flow in javascript is, null-pointer exceptions aren't really much of a problem any more. Where they might have caused a bug, 90% of the time Flow will catch them, and insist that I do a null check and handle that case. And when they do crop up, it's usually more of a serious failure that I'm happy to trigger an exception early, rather than having it propagate furth…

Usually things of form `a && a.b && a.b.c && a.b.c.d` are a sign of a law of demeter violation. This applies to more than javascript. I view code like this as a sign that there might be a better way, as opposed to a stedfast rule. Refactoring to remove these types of violations tends to lead to better code.

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#35

One thing I've been finding increasingly while using Flow in javascript is, null-pointer exceptions aren't really much of a problem any more. Where they might have caused a bug, 90% of the time Flow will catch them, and insist that I do a null check and handle that case. And when they do crop up, it's usually more of a serious failure that I'm happy to trigger an exception early, rather than having it propagate furth…

Just use try{} and keep the secret.

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#36
post #8

> The implementation uses Symbol and Proxy behind the hood so you might need to use appropriate polyfills... Does anyone know of a working Proxy polyfill? I've never been able to find one.

I've seen this one: https://github.com/GoogleChrome/proxy-polyfill

1. You should probably add that link to your read me:

The implementation uses `Symbol` and [`Proxy`](https://github.com/GoogleChrome/proxy-polyfill) behind the hood so you might need to use apropriate polyfills in case you want to support older browsers.

2. Personally, I find the name Nothing a bit too long. Why not use a shorter name like None?

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#37
post #27

If you use Babel 7, you can install a plugin [0] to get the optional chaining syntax [1] that's currently a TC39 Stage 1 proposal! [0] https://www.npmjs.com/package/babel-plugin-transform-optiona... [1] https://github.com/tc39/proposal-optional-chaining

Oh boy, this is just making me miss Swift anymore...

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#39
post #34

One thing I've been finding increasingly while using Flow in javascript is, null-pointer exceptions aren't really much of a problem any more. Where they might have caused a bug, 90% of the time Flow will catch them, and insist that I do a null check and handle that case. And when they do crop up, it's usually more of a serious failure that I'm happy to trigger an exception early, rather than having it propagate furth…

Usually things of form `a && a.b && a.b.c && a.b.c.d` are a sign of a law of demeter violation. This applies to more than javascript. I view code like this as a sign that there might be a better way, as opposed to a stedfast rule. Refactoring to remove these types of violations tends to lead to better code.

Law of demeter applies to code, but in JS the deep property access is actually done often against data (deserialized JSON).

Re: Show HN: Nothing.js – A chainable mock object which always returns itself

#40
post #19

Earlier quoted context omitted.

That’s true, but ostensibly you only use it in places where you expect nulls and don’t intend to debug anything. That’s why Smalltalk, C#, CoffeeScript, and probably JS and TS soon have null chaining.

Objective-C also allows nil to receive messages which then just returns nil also. I’ve always found this really natural in that you can assume something is either valid or null and avoid a whole lot of null checks this way. That said, I’ve never been terribly frustrated by other languages either which throw when calling methods on null. Maybe it’s because of heavy use of certain design patterns that make it so it’s n…

It also means a chained call with an nil in it still complete from start to end. So it has additional overhead, and you better not have side effects in there.

All in all, I'd like to have some kind of "?" operator in Python, I do think the pros are most of the time greater than the cons.

Post reply on HN