Access dialog view/view-model from dialogService.controllers

[timfish]

I've been looking into a few ways to selectively confirm the top dialog with the Enter key on the keyboard.

Firstly I tried using a custom attribute which I use on dialogs that I would like to be 'confirmable' with the enter key:

@inject(Element)
export class EnterPress {
  private element: Element;
  public value: Function;

  constructor(private element: Element) { }

  public attached() { this.element.addEventListener('keypress', this.enterPressed); }

  public detached() { this.element.removeEventListener('keypress', this.enterPressed); }

  private enterPressed = (e: KeyboardEvent) => {
    if (e.keyCode === 13) {
      this.value({ event: e });
      e.preventDefault();
    }
  }
}

This has a few major issues:

• It does not work if the dialog loses focus
• It confirms the 1st dialog even if a 2nd dialog is over the top and the 1st one still has focus

These two may at some point be fixed by issue #1?

In the meantime, I was attempting to do the following:

window.addEventListener('keydown', (event) => {
  if (event.keyCode === 13 && dialogService.controllers.length > 0) {
    const top = dialogService.controllers[dialogService.controllers.length - 1];
    // find html element marked with 'enter-press' attribute, check its not disabled, click it
    // OR
    // call something on the view-model
  }
});

But I have no access to the views or view-models here. I'd rather not resort to iterating over the dialogs in the DOM...

[StrahilKazlachev]

You got me confused. What do you mean by selectively?
We've added a new dialog setting, that will be available in the next release, keyboard: boolean | 'Escape' | 'Enter' | ('Escape' | 'Enter')[] - you still can not specify an output. You can check the DialogRenderer in the rc-1.0.0 branch for impl - it just adds to the current Esc key impl.

[timfish]

You go me confused. What do you mean by selectively?

Ah, I simply meant that I want to selectively/programmatically apply it to dialogs.
Thanks, I'll check out the RC code.

[StrahilKazlachev]

@timfish Does the new setting work for your case? You can specify on dialog basis whether the ENTER will .ok() the current(top) dialog - can be combined with the ESC key.

[timfish]

Not had a chance to try this yet.

What if I want to call something other controller.ok(). For example, if want to call a method on the view-model that does validation checks first? Could canDeactivate() work here to block closing?

[StrahilKazlachev]

So currently you can set up ESC(controller.cancel()) and/or ENTER(controller.ok()), you can not pass any data or specify custom keys and/or handlers.
.canDeactivate() can cancel the closing if it returns false | Promise<false>, and since you can return a Promise you can do some async work if needed.

[timfish]

That should be exactly what I need then.

I did try jspm install aurelia-dialog=github:aurelia/[email protected] but dist doesn't contain the build output for that branch so I'll have to fork it, build it myself and try again.

[StrahilKazlachev]

Yeah, sorry, we commit the dist when making a release.

[timfish]

@StrahilKazlachev
A couple of things:

• Had to change my css from ai-* to ux-*. Is this permanent?
• click.delegate="controller.cancel()" or ok() or any other view-model method from the views no longer works

[StrahilKazlachev]

The ux-* - yes.
About the second, are there any errors in the console? Can you check if the overlay is not on top of the dialog. I'll also check again with my local sample.
Also:

• .open().then(...) => .open().whenClosed(...)
• .openAndYieldController().then(...) => .open().then(...)

[StrahilKazlachev]

@timfish OK, so there is something. I'll try to find and fix it today, in the mean time use trigger instead of delegate.

[timfish]

Out of the office so will check your example later. I'm using await in Typescript on the open.

Nothing in the console. I put a breakpoint in the aurelia-binding delegate handler and it's making it there and the binding context all looks good. Strangely occasionally when stepping through the binding code the calls all work. Seems to suggest it's something promisey?