Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    LeonineKing1199
    @LeonineKing1199
    I'm like the only one here. But I'm allergic to work so I can answer any questions you may have :)
    Mark Moore
    @mmoo9154
    Is there a way to save this transcript? I haven't used gitter before just now
    LeonineKing1199
    @LeonineKing1199
    Um, not that I'm aware of
    Mark Moore
    @mmoo9154
    np
    LeonineKing1199
    @LeonineKing1199
    There's a C++ gitter that I'm a part of too
    So if you ever feel like chatting about C++, there is a gitter for it
    Barney Carroll
    @barneycarroll
    Hi folks!
    I've been working with promises for ages, and
    in the last year I've been using async / await with some delight
    Something I didn't get early on in my playing with async / await was a fair bit of criticism that deemed the proposal redundant since we already had generators
    This was because I'd never really grokked generators, they were too broad in their use cases and I'd never come up with a scenario where I'd used them to significant effect
    Barney Carroll
    @barneycarroll
    However recently I've discovered the power of splitting low level logic into subroutines and I've realised just how useful generators can be
    co was always cited as the empowering toolkit that made generators shine, so I thought I'd come back and read a bit in the hope of getting some more ideas of the possibility space of generators
    Barney Carroll
    @barneycarroll
    And I'm surprised to see that the README says generators and generator functions are now only consumable as yieldables as a backward compatibility measure, with the recommendation being that people use promises instead
    This strikes me as odd, since it suggests that in the modern spec world, co is essentially relegating itself to async / await with special unwrapping behaviour
    Does anyone have any insight as to the rationale behind "avoid yielding generators"?
    LeonineKing1199
    @LeonineKing1199
    I'm not sure I understand the logic as well :P
    Delegating generators just increases the amount of iterations the generator supports
    Maybe it's a pain in the ass to maintain the code? Though I couldn't see how that's true
    It's simple to yield co(...); though so I'm not complaining
    I think it's because in the future, await will only work with promises
    co was built with planned obsolescence in mind. Generator delegation probably is a hurdle to that because it won't work natively with await
    Barney Carroll
    @barneycarroll
    TBH I've had mysterious problems trying to get recursive generators to work anyway, I can't blame co for wanting to keep the API predictable and limit generators to anonymous constructs wrapped in a co call
    LeonineKing1199
    @LeonineKing1199
    I'm glad someone brought some life into this gitter :P
    Barney Carroll
    @barneycarroll
    Haha
    Transient life!
    LeonineKing1199
    @LeonineKing1199
    I think TJ's main goal was to have co be used and then when ES7 hits, people can just replace yield with await and it'll all just work
    Sorry, I keep thinking about the rationale for the delegation deprecation
    Barney Carroll
    @barneycarroll
    Ironic considering the volume of people saying async / await are unnecessary precisely because we have generators / yield
    joystick
    @joystick
    Hi there, looking for advise how can one yield from underscore.js callbacks, e.g. from _.map().
    joystick
    @joystick
    trying to do smth like:
    _.each(transactionTypes, function*(transactionTypes) {
            state[transactionType] = yield db.collection(transactionType).find().toArray(); 
        });
    LeonineKing1199
    @LeonineKing1199
    You can't yield from inside callbakcs
    You'll have to use a for-loop
    joystick
    @joystick
    Thanks @LeonineKing1199 I moving towards it. Could you please check what's wrong with following?
    co(function * () {
        var state = {};
        state.db = yield MongoClient.connect('mongodb://localhost/test');
        return state;
    })
    .then(function(state) {
        console.log(state.db);
        state.transactionTypes = yield state.db.collection('Transaction').distinct('TxnType');
        return state;
    })
    .then(function(state) {
        console.log(state.transactionTypes);
        state.db.close();
    })
    .catch(function(error) {
        console.error(error);
    });
    joystick
    @joystick
    It tells me
    C:\Users\ak\Documents\code\qb\export.js:14
        state.transactionTypes = yield state.db.collection('Transaction').distinct('TxnType');
                                       ^^^^^
    
    SyntaxError: Unexpected identifier
        at exports.runInThisContext (vm.js:53:16)
        at Module._compile (module.js:373:25)
        at Object.Module._extensions..js (module.js:416:10)
        at Module.load (module.js:343:32)
        at Function.Module._load (module.js:300:12)
        at Function.Module.runMain (module.js:441:10)
        at startup (node.js:139:18)
        at node.js:968:3
    joystick
    @joystick
    I think I got the idea - I'm not returning promise from .then().
    LeonineKing1199
    @LeonineKing1199
    Nope
    Actually, why are you even chaining Promises?
    Basically, takes what's inside all your .then functions and put it inside your generator function*
    You can only yield from inside generators
    LYF
    @pod4g
    Hi. there is a statistical analysis tool for performance testing https://github.com/pod4g/hiper/