Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

github.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#11

Post by alangpierce »

reificator wrote: post #8
tzahola wrote: post #2

Yet another layer to go through when debugging. Wonderful! /s

I don't know why you're being fight club ed, this is a serious concern. The places where this comes in handy are already prime candidates for bug hiding locations. Adding this in might remove some of those, but if the cost is that debugging what remains is significantly more difficult, then is it really worth it?

I think the point about debugging is legitimate, and the downvote was because of the sarcastic tone. Someone put a lot of time into this project, so it's nice for feedback to be straightforward and, if possible, constructive.

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#12

Post by Can_Not »

jostylr wrote: post #7

The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done. Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.

You could instead have then and catch actually create and execute the promise. Then you could write without send (unless you really wanted to):

> await msg('hello everyone').to( list).except('John')

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#14

Post by omidh28 »

reificator wrote: post #8
tzahola wrote: post #2

Yet another layer to go through when debugging. Wonderful! /s

I don't know why you're being fight club ed, this is a serious concern. The places where this comes in handy are already prime candidates for bug hiding locations. Adding this in might remove some of those, but if the cost is that debugging what remains is significantly more difficult, then is it really worth it?

Thanks for sharing your feedback, Yes I'm agree on some degrees hopefully I'll add some debugging features into the project. However ClarifyJs is not intended to wrap your whole code but just endpoints that you want to be called more fluently or want to put a layer of abstract over calling functions and passing arguments.

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#15

Post by baddox »

jostylr wrote: post #7

The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done. Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.

I would prefer that API anyway, because it would allow writing reusable code that generates the unsent objects. This is a killer feature of ORMs like Active Record (although in that case you don’t need an explicit “execute” method because it decides to execute the query when you attempt to iterate on the object.)

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#16

Post by d--b »

Oof... syntactic sugar at the cost of obfuscation and configuration.

How is this clearer than normal method calling, when you have to look for a priority number in the config to know which method executes before the other one?

Sorry but I think this is a really bad idea...

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#17

Post by bryanrasmussen »

alangpierce wrote: post #10
jostylr wrote: post #7

The example with the message could just be msg('hello everyone').to( list).except('John').send().then... where send() returns a promise. That is, the message creates an object that is getting modified until it hits the send method and then it is done. Maybe it is just a too simple example to get a point across, but I would want to see an example where this would not work.

My impression is the goal of this library is to make it a little cleaner than the builder pattern because you don't need the `.send()` at the end. Arguably, it's nice to make the syntax a little more concise if the library is there to hide all of the complicated details from you. That said, I get uneasy when reading code like the example send('hello everyone!').to('friends').except('john'); since it doesn't follow my…

I liked it because it reminded me of Ruby's more English like syntax, however someone else made the same comment where I work about it being a source of possible confusion so that is probably true.

I guess otherwise it would need to be something like send('hello everyone').to('friends', 'John'); but now you don't understand what 'John' does unless you read the code - which,I know, realistically people don't always make their methods match the names so you don't really know that except('John') does what you might assume until you read it as well.

But in a theoretical world that was as we would like it to be you could reason from the method name to what the method actually does.

Re: Show HN: ClarifyJs – Overcoming Limits of JavaScript Method Chaining

#18

Post by lozzo »

d--b wrote: post #16

Oof... syntactic sugar at the cost of obfuscation and configuration. How is this clearer than normal method calling, when you have to look for a priority number in the config to know which method executes before the other one? Sorry but I think this is a really bad idea...

I don't think you should apologize. I too think it's a terrible idea. And the irony it's that the author called the library "clarify".
Post reply on HN