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

Order of appearance, or rather, the oldest in the place of the new and old ones dying before no moving all the others. #213

Open
ghost opened this issue Oct 11, 2016 · 2 comments

Comments

@ghost
Copy link

ghost commented Oct 11, 2016

My notifications are to the top.

Now, with the same priority, new notifications appear under the old ones.

1
2
3
4

Why?

I wish that the new notifications appeared "above" the other old and older notifications moved down by one step. So when they die they do not move all the others.

4
3
2
1

I'm wrong, or there isn't an option like that?

Thanks in advance.

@sbatson5
Copy link
Collaborator

Hi @johnunclesam! I think this more a product of the each loop showing the array of flash objects. In your component (where you are most likely injecting the flash message service), you can create a new, reversed array based on the queue:

flashMessages: Ember.inject.service(),

reversedQueue: Ember.computed('flashMessages.queue', function() {
  return this.get('flashMessages.queue').reverseObjects();
})

Then in your template, you can update it to:

{{#each reversedQueue as |flash|}}
  {{#flash-message flash=flash as |component flash|}}
     ... etc.
  {{/flash-message}}
{{/each}}

Now it should be based on the reverse of the queue array and you should get the order you want.

@panthony
Copy link

I face the same issue than @johnunclesam .

The problem with your proposed solution @sbatson5 is that it will move the message with the top priority below the lowest priority whereas the expected behavior (IMO) would be a 2 dimensional sort.

First by priority, then for messages with the same one, sort from the newest to the oldest.

The reversed queue would be sufficient if the priority parameter is not used though.

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

No branches or pull requests

2 participants