3

I often see code like this:

(code completely made up from scratch)

something.someFunction('foobar')
    .then(function(user) {
        var email = user.email();
        return user.getSomething();
    })
    .then(function(something) {
        var metadata = something.metadata();
        return user.getRelation(metadata);
    })
    .then(function(relation) {
        return email.send(relation, metadata);
    })
    .catch(function(err) {
        console.log(err);
    })
;

Is this common practice? Personally, I think it's not very clean nor readable. What are alternatives? All I could come up with is something like put all needed stuff into an object and pass that around instead. However, that might get very large on long promises:

something.someFunction('foobar')
    .then(function(user) {
        return {
            email: user.email(),
            something: user.getSomething(),
        };
    })
    .then(function(state) {
        return {
            email: state.email,
            metadata: something.metadata(),
            relation: user.getRelation(metadata),
            // 'something' is not needed anymore ...
        };
    })
    .then(function(state) {
        return {
            result: email.send(state.relation, state.metadata),
            // and everything else that might be needed later on ...
        };
    })
    .catch(function(err) {
        console.log(err);
    })
;

Would that even still work as expected? If not, what would be a way to create something similar? Again, I just came up with this code from scratch as a pure illustrating example.

Num Lock
  • 742
  • 1
  • 6
  • 32
  • I don't see any bad practice here, it's regular method chaining. Why pass around useless data ? I mean, `something` is used only in the first function, so unless you need it later, I see no need to pass it to the following ones. – xlecoustillier Jul 08 '15 at 12:37
  • Well, `something` is actually needed after the first function, and exactly that is my point: Pass around what is needed and skip the rest. (As the sample won't handle `something` to the third function anymore) – Num Lock Jul 08 '15 at 12:40
  • 1
    You are not hoisting anything here. Hoisting moves all your variable declarations to the top of the function and you declare all your variables as the first line on every function you use. See http://www.adequatelygood.com/JavaScript-Scoping-and-Hoisting.html – devconcept Jul 08 '15 at 12:42
  • @devconcept Sorry, my terminology on JavaScript is probably not the best as I am fairly still a beginner. Yes, it's not hoisting. I meant whatever it is called that affects the scope. `var` here is not a problem, but `const` and `let` would be. (Or am I wrong on that one as well?) Edited the title anyways. Thanks for the hint. – Num Lock Jul 08 '15 at 12:45
  • @NumLock Well `let` and `const` are block scoped while `var` is execution context scoped. If your block is a function it will behave like `var` if is another statement it will probably not – devconcept Jul 08 '15 at 12:52
  • @NumLock Just a clarification of my comment above `let` will not behave exactly like var because `let` declarations are not hoisted. In ES6 the interpreter will throw a Reference error if you try to use a variable before declaring it with let – devconcept Jul 08 '15 at 13:14
  • 1
    The first snippet is indeed bad practise, as it doesn't work :-) If you would have [put the variable declarations in the surrounding scope](http://stackoverflow.com/a/28250700/1048572) it would have worked, but not have been good practise still. [Putting all stuff in an object](http://stackoverflow.com/a/28250693/1048572) might work as well, but only a bit more complicated as `getSomething` and `getRelation` return promises and you need to chain the object stuff. There are much better solutions though. – Bergi Jul 08 '15 at 13:21
  • Marked as duplicate? Whatever this question has in common with the linked one (besides the tags) ... It sure as hell isn't the question, nor the answers. I even knew that specific one. But whatever. I get your point I think ... – Num Lock Jul 09 '15 at 10:17

0 Answers0