Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closes ciena-frost/ember-frost-list#121 #122

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

notmessenger
Copy link
Contributor

This project uses semver, please check the scope of this pr:

  • #none# - documentation fixes and/or test additions
  • #patch# - backwards-compatible bug fix
  • #minor# - adding functionality in a backwards-compatible manner
  • #major# - incompatible API change

CHANGELOG

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 920201e on notmessenger:is-loading-indicator into ** on ciena-frost:master**.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 854db7b on notmessenger:is-loading-indicator into ** on ciena-frost:master**.

itemExpansion: PropTypes.EmberComponent,
loadingType: PropTypes.string,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like this to be change to a component closure rather than relying directly on frost-loading

So the interface would be

{{frost-list
  loading=(component 'frost-loading')
  ...
}}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

{{#if pagination}}
{{#frost-scroll
hook=(concat hookPrefix '-scroll')
{{#if isLoading}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be satisfied using the inverse block of the #each?

@@ -15,8 +15,11 @@
<div class='frost-modal-demo-selector-title'>
Cookbook
{{#link-to 'simple'}}Basic{{/link-to}}
{{#link-to 'simple-loading'}}Basic - Loading{{/link-to}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can put the examples directly into the existing routes - no need to do a duplicate explicitly to demonstrate the loading

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sglanzer The demo app currently uses small viewports for the existing demos so that users don't have to scroll as far to experience the infinite paging experience, not as many records need to be created for the paging screens, etc. Because this viewport is not very tall (due to it's overflow being hidden) the loading indicator does not show in its entirety. In the new routes I created to demo the loading support I have increased the viewport size. If you have any recommendations on how to remedy this or approach it differently I am interested. In either case I am in need of direction on how you wish me to proceed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I don't think we made a conscious decision about the demo height initially, if you can increase it and satisfy your case of showing the loader I'm fine with that. I believe it's easier to use the demo for a reference if you don't have to go through multiple demos to get the data you need (less is more).

Not a big deal though, so if you see value in keeping both I won't block it

Copy link
Contributor

@sglanzer-deprecated sglanzer-deprecated left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to see a component helper interface used for the sub-component and it would be good to explore the need for an explicit isLoading

@notmessenger
Copy link
Contributor Author

@sglanzer Regarding the exploration of the explicit need for isLoading my thinking is that we would need to change the items property definition in the frost-list component - https://github.com/ciena-frost/ember-frost-list/blob/master/addon/components/frost-list.js#L28-L31 - to only accept a Promise rather than an Object or Ember.Object. This way a loading (resolution) state could be monitored.

@sglanzer-deprecated
Copy link
Contributor

@notmessenger ok, let's avoid that for now and stick with the isLoading solution.

@notmessenger
Copy link
Contributor Author

@sglanzer Or we could have it also accept a Promise and if one is passed then the loading state can be inferred. The only way you get this loading indicator functionality is to use a Promise.

@sglanzer-deprecated
Copy link
Contributor

Sure, but an explicit isLoading still won't hurt in that case, so I'm fine with this, just need the adjustment to the way the loading indicator is specified and I'm good to merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants