yield from the template

[davidgoli]

Previously, the only possible loading indicators were loadingText and a CSS background image. This gives a much bigger range of possibilities, such as CSS animations with custom markup.

[kellyselden]

#51. I believe this is already a feature, where you can swap in your own template.

[hhff]

I think it would be nice to Yield from the template - but we should remove the loadingText if there's a block given.

i thiiiiink the syntax is like

{{#if blockGiven}}
  {{yield}}
{{else}}
  ... original template ...
{{/if}}

[davidgoli]

The correct property is hasBlock http://emberjs.com/api/classes/Ember.Component.html#property_hasBlock

... and done

[hhff]

Thanks @davidgoli - can we get a lil' test for this?

[davidgoli]

@hhff sure - mind if I add the ember-cli-htmlbars-inline-precompile package to write an integration test?

[davidgoli]

@hhff Test added. Note that I had to revert to the old-style template helper that is supported by Ember 1.10 (which is the baseline for ember-infinity) but is deprecated in Ember 1.13. I also added the htmlbars-inline-precompile package per current best practice (https://github.com/rwjblue/ember-qunit#component-unit-tests)

[hhff]

@davidgoli - if you merge from master this guy should be passing

[hhff]

Also - can we please add a short description of how to use this to the README ?

[davidgoli]

@hhff Merged, fixed, and README updated.

[hhff]

awesome - can you squash this?

[davidgoli]

Squash it? I don't think I have merge permission, if that's what you mean.

[hhff]

Oh i just mean squash the commits @davidgoli

https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history

We just do this so the Changelog is super clean and clear :)

[davidgoli]

@hhff how does this look?

[hhff]

looks great! Is there a deprecation warning when using the template helper?

[davidgoli]

oh yeah I think so... in reality, it means the same thing as hasBlock, but always returns false on later versions. But, it's still necessary for backwards compatibility as well. What's your recommendation for how to handle this?

[davidgoli]

ie, create a helper, or what?

[hhff]

I'd say the move is to use emberVersionIs in the component to wrap both of those.

We're already using it in the route.js here: https://github.com/hhff/ember-infinity/blob/master/addon/mixins/route.js#L2 so it should be easy to add 👍

[davidgoli]

Looks like that's not quite as easy for the Component case, since hasBlock is a helper not a component property. Fortunately, there's an officially-endorsed polyfill solution: emberjs/ember.js#11430 (comment)

[davidgoli]

Yeah that's passing ember-1.12, ember-1.13, ember-release, and ember-canary locally. Only question is where to put the polyfill.

[hhff]

This is going to effect all components in the host application. Could we do it in the extend call below somehow instead? I don't want to effect the rest of a developer's application. Worse comes to worse - we could do the reopen before the export just on the infinity-loader

Thanks @davidgoli !

[davidgoli]

@hhff isolated the changes to only this component. Please take another look.

[davidgoli]

whoops, forgot to add -u before pushing.

[hhff]

THE MAN! thankyou @davidgoli !

[hhff]

Published: + [email protected]