marcscheib / aurelia-notify Goto Github PK

I'm submitting a ... (check one with "x")

[X] bug report => search github for a similar issue or PR before submitting
[ ] feature request

Current behavior
The Notification controller close returns a Promise which is great. However shouldn't the second invokeLifecycle also be returned ? Otherwise the outer promise (created by the first invokeLifecycle) will conclude without waiting for the inner promise to complete.

Expected behavior
I would expect the inner promise to be returned. That is, instead of having
invokeLifecycle(this.viewModel, 'deactivate')
I would use
return invokeLifecycle(this.viewModel, 'deactivate')

Minimal reproduction of the problem with instructions
N/A - it would complex to report it here.

What is the motivation / use case for changing the behavior?
This is giving us problems because we have notifications in a modal, which we wish to remove before the modal itself closes. However the close()-returned promise ends before the animation is completed and the notification destroyed, hence the notification is still around (although hidden) the next time the modal is opened.

It would be useful to have the close() when the notification removal is complete.

Please tell us about your environment:
Windows 10, Webpack

• Version:
  "aurelia-notify": "^0.7.0",

• Browser: Chrome/Electron

• Language: ES6

• Node (for AoT issues): node --version = 6.9.1

Hi,

Basically a small question/request.

Im creating my own view/view-model, but when i want to use the notify method, i realise i can only send a string through. I would like to send my own model through as well.

I added the following overload to the typings : notify(object: any, settings?: any, level?: string): any;

but this will break if you make any updates.

Any suggestions?

Add a settings type declaration for TS applications.

Add a configuration options which allows to specify whether to scroll to the notification container if a notification pops up. This is especially useful for forms which have the container in the beginning of the form.

Absolute positioned notification containers don't need scroll (+1 for configurable option).

Could you please make this compatible with the recent version of aurelia (rc-1.0.0)? I'm getting

lifecycle.js:10 Uncaught (in promise) TypeError: Cannot read property 'canActivate' of undefined
    at invokeLifecycle (http://dev-local:8835/jspm_packages/github/MarcScheib/[email protected]/lifecycle.js:10:24)
    at http://dev-local:8835/jspm_packages/github/MarcScheib/[email protected]/notification-service.js:60:47

and

Uncaught (in promise) Error: BindingLanguage must implement inspectTextContent().
    at mi (http://dev-local:8835/jspm_packages/npm/[email protected]/aurelia-templating.js:734:11)
    at BindingLanguage.inspectTextContent (http://dev-local:8835/jspm_packages/npm/[email protected]/aurelia-templating.js:751:7)
    at ViewCompiler._compileNode (http://dev-local:8835/jspm_packages/npm/[email protected]/aurelia-templating.js:2532:79)
    at ViewCompiler._compileNode (http://dev-local:8835/jspm_packages/npm/[email protected]/aurelia-templating.js:2552:33)
    at ViewCompiler.compile (http://dev-local:8835/jspm_packages/npm/[email protected]/aurelia-templating.js:2499:12)
    at http://dev-local:8835/jspm_packages/npm/[email protected]/aurelia-templating.js:3146:50

Hi,

First of all: Great work, thank you! =)

I encountered two problems working in Typescript:

1. I installed aurelia-notify via jspm, but it did not download the "aurelia-notify.d.ts" file. I'm not really deep into jspm, so I'm not sure whether this is a general problem of jspm+github or sth fixable.
2. After i got the definitions manually, the typescript compiler said that my calls to .danger(..), .info(..) etc. were missing a second parameter (settings). Are settings supposed to be obligatory or optional?

Currently, new notifications are added to the top of the notification container.

Add an option which allows to revert the order.