Re: [polymer-dev] When do I have to call flush() in wct?

[Michael Giuffrida]

Nice! Thanks for the commit sleuthing. Having it in the docs would be
great, too.

Michael

On Fri, Dec 18, 2015 at 2:51 PM Arthur Evans  wrote:

> Hi Michael,
>
> I know a lot of folks are out on vacation so you may not get a quick
> authoritative answer. So here's a semi-quick, semi-authoritative answer.
>
> Based on a discussion earlier this week with Steve and Kevin, I believe
> that this is now the expected behavior of Polymer.dom.flush(), and I'm
> planning on adding it to the documentation.
>
> Specifically, this feature was added in 1.0.8 in the following PR:
>
> https://github.com/Polymer/polymer/pull/2090
>
> The feature is described in the PR, rather than being a side-effect of an
> unrelated change.
>
> Hope this semi-answer is semi-helpful,
> Arthur
>
>
> On Wed, Dec 16, 2015 at 12:03 AM, Michael Giuffrida <
> michae...@chromium.org> wrote:
>
>> > In general, calling `Polymer.dom.flush` provides a guarantee that
>> these tasks complete synchronously.
>>
>> sorry to dig up an old thread, but I was poking around in Polymer 1.0.4
>> today and discovered that `Polymer.dom.flush` didn't guarantee
>> `dom-if` template rendering after changing the `if` property. Instead, 
>> Polymer.Async
>> was necessary to ensure the `if` took effect
>> .
>>
>> `Polymer.dom.flush` does seem to work in recent versions of Polymer, but
>> the fact that it was insufficient in a previous 1.0 release worries me. We
>> rely on this in tests to avoid excessive async functions. I just wanted to
>> clarify whether we can consider `Polymer.dom.flush` sufficient to stamp the
>> template nowadays, or if it's just an implementation detail that may revert
>> to 1.0.4 behavior at any time.
>>
>> On Mon, Jul 27, 2015 at 10:30 AM Steve Orvell  wrote:
>>
>>> For efficiency, Polymer queues dynamic changes that provoke Shady DOM
>>> distribution (changes that fill insertion points, e.g. ) and
>>> template rendering (e.g. `dom-if` and `dom-repeat`) and processes them at
>>> microtask timing. In addition, the Custom Elements polyfill processes
>>> dynamic dom changes (upgrading elements and calling attached/detached) at
>>> microtask timing.
>>>
>>> In general, calling `Polymer.dom.flush` provides a guarantee that these
>>> tasks complete synchronously.
>>>
>>> On Thu, Jul 16, 2015 at 7:25 PM, Michael Giuffrida <
>>> michae...@chromium.org> wrote:
>>>
 It would be really nice if anyone could provide a more detailed answer
 to this and similar questions: It's not clear what operations are supposed
 to be synchronous or asynchronous (and when async operations are at task
 level vs. microtask level), which affects tests but also some more
 complicated UI logic.

 I started a thread last week which didn't get any responses. I would
 appreciate even a simple "we make no guarantees" response if that's the
 case, because it would help knowing how defensive our code should be.

 Michael

 On Thu, Jul 16, 2015 at 4:02 PM, 'Daniel Freedman' via Polymer <
 polymer-dev@googlegroups.com> wrote:

> Generally you can get away with not using flush.
>
> You may still need flush for testing element lifecycle callbacks in
> polyfilled browsers, or measuring DOM, but I expect very few cornercases
> like that.
>
> On Thu, Jul 16, 2015 at 10:46 AM,  wrote:
>
>> With Polymer 1.0, observers are now evaluated synchronously.  If I
>> have an element whose behavior is driven by observers on attributes, and
>> everything appears to work in synchronous tests, is there any reason to
>> call flush()?  That is, is it necessary that I call it before/after each
>> test?
>>
>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Polymer" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to polymer-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> Follow Polymer on Google+: plus.google.com/107187849809354688692
> ---
> You received this message because you are subscribed to the Google
> Groups "Polymer" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to polymer-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/polymer-dev/CAAUAVAhtWUNOMEw8Zm2Nq5JVA0Q4ihDEtgPJ4pDjRVqZHk1ENA%40mail.gmail.com
> 

Re: [polymer-dev] When do I have to call flush() in wct?

['Arthur Evans' via Polymer]

Hi Michael,

I know a lot of folks are out on vacation so you may not get a quick
authoritative answer. So here's a semi-quick, semi-authoritative answer.

Based on a discussion earlier this week with Steve and Kevin, I believe
that this is now the expected behavior of Polymer.dom.flush(), and I'm
planning on adding it to the documentation.

Specifically, this feature was added in 1.0.8 in the following PR:

https://github.com/Polymer/polymer/pull/2090

The feature is described in the PR, rather than being a side-effect of an
unrelated change.

Hope this semi-answer is semi-helpful,
Arthur


On Wed, Dec 16, 2015 at 12:03 AM, Michael Giuffrida 
wrote:

> > In general, calling `Polymer.dom.flush` provides a guarantee that these
> tasks complete synchronously.
>
> sorry to dig up an old thread, but I was poking around in Polymer 1.0.4
> today and discovered that `Polymer.dom.flush` didn't guarantee
> `dom-if` template rendering after changing the `if` property. Instead, 
> Polymer.Async
> was necessary to ensure the `if` took effect
> .
>
> `Polymer.dom.flush` does seem to work in recent versions of Polymer, but
> the fact that it was insufficient in a previous 1.0 release worries me. We
> rely on this in tests to avoid excessive async functions. I just wanted to
> clarify whether we can consider `Polymer.dom.flush` sufficient to stamp the
> template nowadays, or if it's just an implementation detail that may revert
> to 1.0.4 behavior at any time.
>
> On Mon, Jul 27, 2015 at 10:30 AM Steve Orvell  wrote:
>
>> For efficiency, Polymer queues dynamic changes that provoke Shady DOM
>> distribution (changes that fill insertion points, e.g. ) and
>> template rendering (e.g. `dom-if` and `dom-repeat`) and processes them at
>> microtask timing. In addition, the Custom Elements polyfill processes
>> dynamic dom changes (upgrading elements and calling attached/detached) at
>> microtask timing.
>>
>> In general, calling `Polymer.dom.flush` provides a guarantee that these
>> tasks complete synchronously.
>>
>> On Thu, Jul 16, 2015 at 7:25 PM, Michael Giuffrida <
>> michae...@chromium.org> wrote:
>>
>>> It would be really nice if anyone could provide a more detailed answer
>>> to this and similar questions: It's not clear what operations are supposed
>>> to be synchronous or asynchronous (and when async operations are at task
>>> level vs. microtask level), which affects tests but also some more
>>> complicated UI logic.
>>>
>>> I started a thread last week which didn't get any responses. I would
>>> appreciate even a simple "we make no guarantees" response if that's the
>>> case, because it would help knowing how defensive our code should be.
>>>
>>> Michael
>>>
>>> On Thu, Jul 16, 2015 at 4:02 PM, 'Daniel Freedman' via Polymer <
>>> polymer-dev@googlegroups.com> wrote:
>>>
 Generally you can get away with not using flush.

 You may still need flush for testing element lifecycle callbacks in
 polyfilled browsers, or measuring DOM, but I expect very few cornercases
 like that.

 On Thu, Jul 16, 2015 at 10:46 AM,  wrote:

> With Polymer 1.0, observers are now evaluated synchronously.  If I
> have an element whose behavior is driven by observers on attributes, and
> everything appears to work in synchronous tests, is there any reason to
> call flush()?  That is, is it necessary that I call it before/after each
> test?
>
> Follow Polymer on Google+: plus.google.com/107187849809354688692
> ---
> You received this message because you are subscribed to the Google
> Groups "Polymer" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to polymer-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

 Follow Polymer on Google+: plus.google.com/107187849809354688692
 ---
 You received this message because you are subscribed to the Google
 Groups "Polymer" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to polymer-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/polymer-dev/CAAUAVAhtWUNOMEw8Zm2Nq5JVA0Q4ihDEtgPJ4pDjRVqZHk1ENA%40mail.gmail.com
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>> Follow Polymer on Google+: 

Re: [polymer-dev] When do I have to call flush() in wct?

[Michael Giuffrida]

> In general, calling `Polymer.dom.flush` provides a guarantee that these
tasks complete synchronously.

sorry to dig up an old thread, but I was poking around in Polymer 1.0.4
today and discovered that `Polymer.dom.flush` didn't guarantee
`dom-if` template rendering after changing the `if` property. Instead,
Polymer.Async
was necessary to ensure the `if` took effect
.

`Polymer.dom.flush` does seem to work in recent versions of Polymer, but
the fact that it was insufficient in a previous 1.0 release worries me. We
rely on this in tests to avoid excessive async functions. I just wanted to
clarify whether we can consider `Polymer.dom.flush` sufficient to stamp the
template nowadays, or if it's just an implementation detail that may revert
to 1.0.4 behavior at any time.

On Mon, Jul 27, 2015 at 10:30 AM Steve Orvell  wrote:

> For efficiency, Polymer queues dynamic changes that provoke Shady DOM
> distribution (changes that fill insertion points, e.g. ) and
> template rendering (e.g. `dom-if` and `dom-repeat`) and processes them at
> microtask timing. In addition, the Custom Elements polyfill processes
> dynamic dom changes (upgrading elements and calling attached/detached) at
> microtask timing.
>
> In general, calling `Polymer.dom.flush` provides a guarantee that these
> tasks complete synchronously.
>
> On Thu, Jul 16, 2015 at 7:25 PM, Michael Giuffrida  > wrote:
>
>> It would be really nice if anyone could provide a more detailed answer to
>> this and similar questions: It's not clear what operations are supposed to
>> be synchronous or asynchronous (and when async operations are at task level
>> vs. microtask level), which affects tests but also some more complicated UI
>> logic.
>>
>> I started a thread last week which didn't get any responses. I would
>> appreciate even a simple "we make no guarantees" response if that's the
>> case, because it would help knowing how defensive our code should be.
>>
>> Michael
>>
>> On Thu, Jul 16, 2015 at 4:02 PM, 'Daniel Freedman' via Polymer <
>> polymer-dev@googlegroups.com> wrote:
>>
>>> Generally you can get away with not using flush.
>>>
>>> You may still need flush for testing element lifecycle callbacks in
>>> polyfilled browsers, or measuring DOM, but I expect very few cornercases
>>> like that.
>>>
>>> On Thu, Jul 16, 2015 at 10:46 AM,  wrote:
>>>
 With Polymer 1.0, observers are now evaluated synchronously.  If I have
 an element whose behavior is driven by observers on attributes, and
 everything appears to work in synchronous tests, is there any reason to
 call flush()?  That is, is it necessary that I call it before/after each
 test?

 Follow Polymer on Google+: plus.google.com/107187849809354688692
 ---
 You received this message because you are subscribed to the Google
 Groups "Polymer" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to polymer-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Polymer" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to polymer-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/polymer-dev/CAAUAVAhtWUNOMEw8Zm2Nq5JVA0Q4ihDEtgPJ4pDjRVqZHk1ENA%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Polymer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to polymer-dev+unsubscr...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/polymer-dev/CACi5S_1DeF4B%2BkgPzwpW8rt%3DH1dw%2B2%3D1C_BbGqgdzuD5ZtPpQw%40mail.gmail.com
>> 
>> .
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>

Follow Polymer on Google+: plus.google.com/107187849809354688692
--- 
You received this message because you are subscribed to the Google 

[polymer-dev] When do I have to call flush() in wct?

[aroman]

With Polymer 1.0, observers are now evaluated synchronously.  If I have an 
element whose behavior is driven by observers on attributes, and everything 
appears to work in synchronous tests, is there any reason to call flush()? 
 That is, is it necessary that I call it before/after each test?

Follow Polymer on Google+: plus.google.com/107187849809354688692
--- 
You received this message because you are subscribed to the Google Groups 
Polymer group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to polymer-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [polymer-dev] When do I have to call flush() in wct?

[Michael Giuffrida]

It would be really nice if anyone could provide a more detailed answer to
this and similar questions: It's not clear what operations are supposed to
be synchronous or asynchronous (and when async operations are at task level
vs. microtask level), which affects tests but also some more complicated UI
logic.

I started a thread last week which didn't get any responses. I would
appreciate even a simple we make no guarantees response if that's the
case, because it would help knowing how defensive our code should be.

Michael

On Thu, Jul 16, 2015 at 4:02 PM, 'Daniel Freedman' via Polymer 
polymer-dev@googlegroups.com wrote:

 Generally you can get away with not using flush.

 You may still need flush for testing element lifecycle callbacks in
 polyfilled browsers, or measuring DOM, but I expect very few cornercases
 like that.

 On Thu, Jul 16, 2015 at 10:46 AM, aro...@flux.io wrote:

 With Polymer 1.0, observers are now evaluated synchronously.  If I have
 an element whose behavior is driven by observers on attributes, and
 everything appears to work in synchronous tests, is there any reason to
 call flush()?  That is, is it necessary that I call it before/after each
 test?

 Follow Polymer on Google+: plus.google.com/107187849809354688692
 ---
 You received this message because you are subscribed to the Google Groups
 Polymer group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to polymer-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com
 https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.


  Follow Polymer on Google+: plus.google.com/107187849809354688692
 ---
 You received this message because you are subscribed to the Google Groups
 Polymer group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to polymer-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/polymer-dev/CAAUAVAhtWUNOMEw8Zm2Nq5JVA0Q4ihDEtgPJ4pDjRVqZHk1ENA%40mail.gmail.com
 https://groups.google.com/d/msgid/polymer-dev/CAAUAVAhtWUNOMEw8Zm2Nq5JVA0Q4ihDEtgPJ4pDjRVqZHk1ENA%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.


Follow Polymer on Google+: plus.google.com/107187849809354688692
--- 
You received this message because you are subscribed to the Google Groups 
Polymer group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to polymer-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/CACi5S_1DeF4B%2BkgPzwpW8rt%3DH1dw%2B2%3D1C_BbGqgdzuD5ZtPpQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [polymer-dev] When do I have to call flush() in wct?

['Daniel Freedman' via Polymer]

Generally you can get away with not using flush.

You may still need flush for testing element lifecycle callbacks in
polyfilled browsers, or measuring DOM, but I expect very few cornercases
like that.

On Thu, Jul 16, 2015 at 10:46 AM, aro...@flux.io wrote:

 With Polymer 1.0, observers are now evaluated synchronously.  If I have an
 element whose behavior is driven by observers on attributes, and everything
 appears to work in synchronous tests, is there any reason to call flush()?
 That is, is it necessary that I call it before/after each test?

 Follow Polymer on Google+: plus.google.com/107187849809354688692
 ---
 You received this message because you are subscribed to the Google Groups
 Polymer group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to polymer-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com
 https://groups.google.com/d/msgid/polymer-dev/adc4db0a-459d-4abf-ab8f-6453dae62213%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.


Follow Polymer on Google+: plus.google.com/107187849809354688692
--- 
You received this message because you are subscribed to the Google Groups 
Polymer group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to polymer-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/CAAUAVAhtWUNOMEw8Zm2Nq5JVA0Q4ihDEtgPJ4pDjRVqZHk1ENA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.