MD Downloads: handle date hiding/showing more sanely

MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:
* we've had issues in the past testing multiple items in an iron-list
  (and this test would require at least 2 items to be useful)
* you're not really supposed to use or depend on the physical items
  of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/9ce83c55f556e739b053e6be5f0034870be47c37
Cr-Commit-Position: refs/heads/master@{#427883}

[Dan Beam, 2016-10-26 19:24:02]

Description was changed from

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:

a) we've had issues in the past testing multiple items in an iron-list
   (and this test would require at least 2 items to be useful)

b) you're not really supposed to use or depend on the physical items
   of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
==========

to

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:

a) we've had issues in the past testing multiple items in an iron-list
   (and this test would require at least 2 items to be useful)

b) you're not really supposed to use or depend on the physical items
   of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2016-10-26 19:24:46]

Description was changed from

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:

a) we've had issues in the past testing multiple items in an iron-list
   (and this test would require at least 2 items to be useful)

b) you're not really supposed to use or depend on the physical items
   of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:
* we've had issues in the past testing multiple items in an iron-list
  (and this test would require at least 2 items to be useful)
* you're not really supposed to use or depend on the physical items
  of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2016-10-26 19:24:56]

The CQ bit was checked by dbeam@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 19:25:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 19:35:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 19:35:38]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[dpapad, 2016-10-26 21:50:11]

lgtm

[Dan Beam, 2016-10-26 22:14:51]

The CQ bit was checked by dbeam@chromium.org

[commit-bot: I haz the power, 2016-10-26 22:15:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 23:55:46]

Description was changed from

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:
* we've had issues in the past testing multiple items in an iron-list
  (and this test would require at least 2 items to be useful)
* you're not really supposed to use or depend on the physical items
  of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:
* we've had issues in the past testing multiple items in an iron-list
  (and this test would require at least 2 items to be useful)
* you're not really supposed to use or depend on the physical items
  of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[commit-bot: I haz the power, 2016-10-26 23:55:47]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-26 23:58:21]

Description was changed from

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:
* we've had issues in the past testing multiple items in an iron-list
  (and this test would require at least 2 items to be useful)
* you're not really supposed to use or depend on the physical items
  of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
MD Downloads: handle date hiding/showing more sanely

Previously, items where created by accessing the physical DOM. As in:
someElementItem.hideDate = true/false. But then hideDate was moved to
an item's data. I accidentally left a property binding around.
Additionally, changing .data.hideDate doesn't actually trigger observers
in iron-list to fire as it's changing a sub-property of a complex
object. So instead, use the .set() API to ensure iron-list is notified
so it can update the template instance's data for the physical itmes it
owns.

It may be possible to test this, but:
* we've had issues in the past testing multiple items in an iron-list
  (and this test would require at least 2 items to be useful)
* you're not really supposed to use or depend on the physical items
  of an iron-list, which is actually what we'd need to check

R=dpapad@chromium.org
BUG=656580
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/9ce83c55f556e739b053e6be5f0034870be47c37
Cr-Commit-Position: refs/heads/master@{#427883}
==========

[commit-bot: I haz the power, 2016-10-26 23:58:22]

Patchset 1 (id:??) landed as
https://crrev.com/9ce83c55f556e739b053e6be5f0034870be47c37
Cr-Commit-Position: refs/heads/master@{#427883}