Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 18 22:20
    greenkeeper[bot] labeled #5391
  • Oct 18 22:20
    greenkeeper[bot] opened #5391
  • Oct 18 22:20

    greenkeeper[bot] on can-observable-mixin-1.0.3

    fix(package): update can-observ… (compare)

  • Oct 18 19:08
    cherifGsoul labeled #5390
  • Oct 18 19:07
    cherifGsoul opened #5390
  • Oct 18 18:45
    greenkeeper[bot] labeled #5389
  • Oct 18 18:45
    greenkeeper[bot] opened #5389
  • Oct 18 18:45

    greenkeeper[bot] on can-observable-bindings-1.3.0

    fix(package): update can-observ… (compare)

  • Oct 18 18:29

    matthewp on master

    Update dist for release (compare)

  • Oct 18 18:29

    matthewp on v6.1.3

    Update dist for release 6.1.3 (compare)

  • Oct 18 17:59

    matthewp on can-observable-array-1.0.2

    (compare)

  • Oct 18 17:59

    matthewp on master

    fix(package): update can-observ… Merge pull request #5388 from c… (compare)

  • Oct 18 17:59
    matthewp closed #5388
  • Oct 18 16:46
    greenkeeper[bot] labeled #5388
  • Oct 18 16:46
    greenkeeper[bot] opened #5388
  • Oct 18 16:46

    greenkeeper[bot] on can-observable-array-1.0.2

    fix(package): update can-observ… (compare)

  • Oct 18 12:45
    greenkeeper[bot] labeled #5387
  • Oct 18 12:45
    greenkeeper[bot] opened #5387
  • Oct 18 12:45

    greenkeeper[bot] on can-stache-element-1.0.2

    fix(package): update can-stache… (compare)

  • Oct 18 09:49
    chasenlehara edited #5384
Dovid Bleier
@dbleier
why would what be part of my zone?
Thomas Sieverding
@Bajix
can-wait
Also, can-wait seems kind of like a hacky approach to control flow
Dovid Bleier
@dbleier
I don't know. I just stepped into setTimeout and I see it's calling can-wait. I think I am still on donejs 0.6.0
Thomas Sieverding
@Bajix
I see
Dovid Bleier
@dbleier
I didn't choose this, seems donejs did
Thomas Sieverding
@Bajix
I don’t know enough here to give you a good answer
Dovid Bleier
@dbleier
I would be happy to use standard js setTimeout, unless someone has a better idea
thanks for trying
Kevin Phillips
@phillipskevin
can you try wrapping that code so it won’t run on the server?
if (System.isPlatform(‘window’)) { … }
Dovid Bleier
@dbleier
what do you mean? I am not using can-ssr, I am running in the browser on a simple python http server with development.html
Kevin Phillips
@phillipskevin
oh
I didn’t think setTimeout would be overridden on the client
Dovid Bleier
@dbleier
but it seems to be.
when I stepped into setTimeout I got
        return new Override(g, "setTimeout", function(setTimeout){
            return function(fn, timeout){
                var callback = waitWithinRequest(function(){
                    delete request.ids[id];
                    return fn.apply(this, arguments);
                });
                var timeoutId = setTimeout.call(this, callback, timeout);
                var id = timeoutId;
                if(isNode) {
                    id = timeoutId.__timeoutId = globalTimeoutId++;
                }
                request.ids[id] = timeoutId;
                return timeoutId;
            }
        });
Kevin Phillips
@phillipskevin
maybe @matthewp can weigh in
Matthew Phillips
@matthewp
Yeah, if you are recursively calling setTimeout you will want to ignore that
you can do var ignore = require('can-wait/ignore')
which allows you to wrap some code you want to run outside of the zone
var fn = ignore(function() { setTimeout(function{ .... } } )
fn(); // You'll get the real setTimeout
Thomas Sieverding
@Bajix
@matthewp What is can-wait being used for? Compatibility layer for SSR?
Matthew Phillips
@matthewp
Yes, it is how we know when rendering is complete on the server
Thomas Sieverding
@Bajix
I was under the impression that only deferreds mattered
Matthew Phillips
@matthewp
In 0.5.0 we forced you to do this.attr("@root").waitFor(deferred)
but in 0.6.0 we added can-wait
which prevents the need for that
Thomas Sieverding
@Bajix
So you’re hijacking timers & promises instead of doing a root level Promise.all
Matthew Phillips
@matthewp
we're hijacking async code so that we are aware of when it happens
so you don't have to manually tell us all of your deferreds
Thomas Sieverding
@Bajix
That has unintended consequences though
Matthew Phillips
@matthewp
what are those consequences?
Thomas Sieverding
@Bajix
For example, when I worked at Pluto, we would use promises both in our A/B testing flow, and for wrapping modal life cycles to do complex chaining
I can think of dozens of cases in which we’ve used promises & timers in which we wouldn’t want those to prevent SSR
Matthew Phillips
@matthewp
You were using promises that didn't result in the UI changing?
That is the purpose, to know when rendering is complete
Thomas Sieverding
@Bajix
I suppose we could have disabled those modals if we were rendering server side
It would result in UI changing, however there would be a sizable delay
Matthew Phillips
@matthewp
Yes, you can selectively render stuff of course
use helpers to only render certain parts in the client
Thomas Sieverding
@Bajix
can-wait always gets loaded?
Matthew Phillips
@matthewp
it's used by done-autorender
so if you're not using that, no it does not
Thomas Sieverding
@Bajix
I see
Matthew Phillips
@matthewp
by the way, angular 2 has essentially the same sort of thing.
Thomas Sieverding
@Bajix
Feels dirty ;x
Matthew Phillips
@matthewp
for their ssr solution
Thomas Sieverding
@Bajix
But I suppose that’s acceptable for SSR
Matthew Phillips
@matthewp
It only applies to the initial render