fastdom.nextJob?

[alekseykulikov]

Hi @wilsonpage, thank you for the library! I have played with it a little bit, and wish to have one really helpful method:

/**
 * Schedule fastdom read/write operation.
 * Also passes additional `args` to `cb` to perform short forms like:
 *
 *    nextJob(activate.card, app.get('cardId'));
 */

function nextJob(cb) {
  var args = slice.call(arguments, 1);

  fastdom.write(function() {
    fastdom.read(function() { cb.apply(null, args) });
  });
}

It basically adds callback to read/write queue. It's really useful when you write tests, or need to perform something, after fastdom operations done. It will help to avoid callbacks support, because fastdom already has their scheduler, and you can say exactly, when all read/writes done.

[bennybennet]

Hi @ask11 , i made somenthing similar for experiment and pushed it to my fastdom fork here: https://github.com/bennybennet/fastdom/commit/7331cc1eac6c71f6e3d3cf4edc14c36a6e3186c9 I just have done it in 10 Minutes without deep tests, so no warranty or somenthing. ;-)

I like the idea that you can specify an operation to follow after another specific operation. One can do it via:

fastdom.read(function(){
  // read ops 
}).then(function() {
  fastdom.write(function(){
    // write ops and it's save to use 
    // read values from above read op
  });
});

What do you think?

Regards, Benny

[alekseykulikov]

Hi @bennybennet, Promises look good with fastdom. It seems that node's async patterns (Promise, Stream) eventually come to DOM core, and in future we will all work in web differently. Ugly sync API's doing IO like localStorage, sync AJAX, alert, confirm are already becoming a past.

[trullock]

A convenience method would be nice

fastdom.read(function(){
  // read ops 
}).thenWrite(function() {
    // write ops and it's save to use 
    // read values from above read op
});

although seeing as write occur after reads anyway, perhaps only the reverse makes sense

fastdom.write(function(){

}).thenRead(function() {

});

[bennybennet]

Thanks for your feedback you both. Yep, i was thinking about using thenRead / thenWrite terminology but just using "then" made it easier instead and it goes well along with promises terminology as @ask11 mentioned

Btw: I made a little bugfix inside my fork: https://github.com/bennybennet/fastdom/commit/2b5c4229c53d33773c48c0a82e8dd700c7fceb57

[trullock]

I agree with being consistent with promises, then() should be supported, but i figured it might as well also include a thenRead/thenWrite because for me at least, thats all i'll ever be doing in a fastdom then (reading or writing).

[alekseykulikov]

Great ideas! For me it looks like a fastdom plugin case, for example fastdom-then, which extends default fastdom methods.

[trullock]

agree, dont want to pollute the core

[wilsonpage]

Fully agree. Any opinionated syntax should be a plugin. FastDom core should be as simple as it possibly can be.

Personally I would like to see a syntax like:

fastdom.read(before).write(after);

Seems to keep the interface even simpler. Not sure if it confuses things...?

Are people are expecting chaining to return the main FastDom instance...? On 12 Dec 2013 10:16, "Aleksey Kulikov" notifications@github.com wrote:

Great ideas! For me it looks like a fastdom plugin case, for example fastdom-then, which extends default fastdom methods.

— Reply to this email directly or view it on GitHubhttps://github.com/wilsonpage/fastdom/issues/38#issuecomment-30403977 .

[trullock]

I don't feel theres any need to deviate from the promises paradigm. keeps things grokkable.

Might get in a mess if you chain, could lead people to think its working like jQuery.

Id prefer the keep the then prefix, but maybe thats just me

[bennybennet]

I personally would expect to get the FastDom instance when using chaining. I think most guys would also assume that this chaining is synchronous. I wouldn't like to see programatically forced sync chaining here.

I totally go with trullock and prefer the then prefix.

***edit: Should thing about to use real promises in FastDom as it landet nativly in JS? http://www.html5rocks.com/en/tutorials/es6/promises/

[wilsonpage]

A promise API is not available as an extension. Feedback appreciated :)