adopted-ember-addons / adopted-ember-addons/ember-cli-flash

Building computed properties around the queue

Offen
#323 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
TypeScript
Sterne
355
Forks
118
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

I'm working on a project where, for a number of reasons, I'd like to know how many messages are currently in the flash messages service. I'd use those to compute some properties and control application state. But I cannot figure out how to accurately listen for changes to the queue. If my `application.js` injects the service as `flashMessages`, I was thinking I'd be able to do something like:

```hasFlashMessages: Ember.computed('flashMessages.queue', function....```

or

```hasFlashMessages: Ember.computed('flashMessages.queue.@each', function....```

or

```hasFlashMessages: Ember.computed('flashMessages.queue.[]', function....```

or something to that effect. None of these work. What has worked is doing it at a granular level in the corresponding HBS files:

```
{{#if (and flashMessages.queue flashMessages.queue.length))}}
...
{{/if}}
```

Furthermore, when I try to use the Handlebars `log` helper, I get some strange results:

`{{log flashMessages.queue}}` --> only logs once on initial render and never again, regardless of number of messages in the queue
`{{log flashMessages.queue.length}}` --> consistently logs each time the queue grows and shrinks.

I'm fine with my workaround for now, but I'd love to have slightly more control over this as my application grows in complexity.

Is there something I'm missing? Something I could do to start building computed properties around the number of messages in the flash service? This aside, we love the package! It's been extremely useful for us.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.