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

Multiple Named Queues #153

Open
lmcardle opened this issue Apr 5, 2016 · 5 comments
Open

Multiple Named Queues #153

lmcardle opened this issue Apr 5, 2016 · 5 comments

Comments

@lmcardle
Copy link

lmcardle commented Apr 5, 2016

Has there been any thought into having multiple named queues, instead of just one queue as it exist today? My use case is that I have 2 sections on the page for flash type notifications...eventually there may be 3. Ideally, I would like to use this exact same component for all of them, the hbs code would simply loop over a different queue, i.e.:

{{#each flashMessages.queueFoo as |flash|}}
  {{! flash from queue named foo}}
{{/each}}

{{#each flashMessages.queueBar as |flash|}}
  {{! flash from queue named bar}}
{{/each}}

If there has not been any previous discussion on this...any thoughts on doing this? I would be happy to do the work and submit a pull request, but first I wanted to see if this has been previously discussed.

@poteto
Copy link
Collaborator

poteto commented Apr 5, 2016

There hasn't been prior discussion, but I'd be open to this with some thought around:

  1. How will consuming apps specify names for multiple queues? In the config, I presume?
  2. What is the additional API to specify the queue for each flash message?
    • What is the default behavior?

@GCheung55
Copy link

I like the idea for different queues to handle different tiers of messaging:

  1. Application tier.
    • Imagine an error from model save in the route or controller showing a flash message at the top of the app.
  2. Component tier.
    • Imagine multiple components with an input field of their own that saves on change, a success or error would display in close proximity to that field.

In response to your question, @poteto:

  1. I think config would be the right place.
  2. This ties in with where the queues are configured. A queue would be specified as an option, defaulting to the default queue. If the queue doesn't exist, throw.
// Throw here if `foo` queue doesn't exist.
flashMessages.success(message, {queue: 'foo'});
{{#each flashMessages.queue.foo as |flash|}}
    {{! flash from queue named foo}}
{{/each}}

@keighl
Copy link

keighl commented Oct 12, 2016

The addon is actually flexible enough to do this as is. Since we can pass in arbitrary extra values to a flash message, a flash "context" is pretty trivial:

export default Ember.Component.extend({
    flashMessages: Ember.inject.service("flashMessages"),

    // Create a filtered flash queue by ctx
    flashQueue: Ember.computed.filterBy("flashMessages.queue", "ctx", "foo"),

    actions: {
        doSomething() {
            flashMessages.success("Success!", {ctx: "foo"});
        }
    }
});
{{#each flashQueue as |flash|}}
  {{flash-message flash=flash}}
{{/each}}

... only shows foo contextual messages.

@shime
Copy link

shime commented Jun 16, 2017

@keighl this is not a solution to this problem since that will display flash message in the default queue as well.

@keighl
Copy link

keighl commented Jun 19, 2017

@shime If you're using the default queue, I suppose. When I implemented this context thing last year in a project, I didn't use the default queue since the whole point was that I needed contextual/scoped flashes.

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

5 participants