ModalDialogParams - allow ability to be tokenized, provide differently or remove

[NathanWalker]

In an attempt to integrate modal handling seamlessly across web + {N} shared codebase, ModalDialogParams presents a problem in the way it is currently designed.

Instead of:

const modalParams = new ModalDialogParams(options.context, closeCallback);

        const providers = ReflectiveInjector.resolve([
            { provide: Page, useValue: page },
            { provide: ModalDialogParams, useValue: modalParams },  // let's remove this
        ]);

Perhaps the params could be simply lifted off the ModalDialogService itself and do away with ModalDialogParams altogether to do something like this:

constructor(private modal: ModalDialogService) {}

public close() {
  let optionalArgs: any = {
    anyData: 'test'
  };
  this.modal.close(optionalArgs);
}

Could look something like:

@Injectable()
export class ModalDialogService {
    public static closeCallback: Function;
    public context: any;
    private containerRef: ViewContainerRef;

   // etc.

  public close(args) {
    this.context = undefined; // clear any previously passed context
    ModalDialogService.closeCallback(...args);
  }

  public showModal(type: Type<any>, options: ModalDialogOptions): Promise<any> {
        let viewContainerRef = options.viewContainerRef || this.containerRef;

        if (!viewContainerRef) {
            throw new Error("No viewContainerRef: Make sure you pass viewContainerRef in ModalDialogOptions.");
        }

        const parentPage: Page = viewContainerRef.injector.get(Page);
        const resolver: ComponentFactoryResolver = viewContainerRef.injector.get(ComponentFactoryResolver);
        const pageFactory: PageFactory = viewContainerRef.injector.get(PAGE_FACTORY);

        this.context = options.context; // allow shown components to access context

        return new Promise((resolve, reject) => {
            setTimeout(() => ModalDialogService.showDialog(type, options, resolve, viewContainerRef, resolver, parentPage, pageFactory), 10);
        });
    }

  private static showDialog(
        type: Type<any>,
        options: ModalDialogOptions,
        doneCallback,
        containerRef: ViewContainerRef,
        resolver: ComponentFactoryResolver,
        parentPage: Page,
        pageFactory: PageFactory): void {

        const page = pageFactory({ isModal: true, componentType: type });

        let detachedLoaderRef: ComponentRef<DetachedLoader>;
        ModalDialogService.closeCallback = (...args) => {
            doneCallback.apply(undefined, args);
            page.closeModal();
            detachedLoaderRef.destroy();
        };

        // etc.

Simplifying setup by only needing to work with 1 service ModalDialogService instead of 2. It would also make tokenized setups for code sharing between web + {N} more achievable.

If this makes sense, I can offer a PR for this soon.

/cc @vakrilov

[vakrilov]

Hi,
The ModalDialogService can actually be a just a static method - showModal().
Currently, the only reason to keep it a class, is to maintain a back-compatibility for people who are still using it with the 'modal-dialog-host' directive, instead of passing viewContainerRef in the options.

My preference would be to avoid keeping any state inside the ModalDialogService as this will make it more robust. For example, if we keep the context of the currently opened dialog inside the service - you will have to watch out for cases when someone does showModlal() while a dialog is opened and thus overriding the original context. Also, it might lead to the context object leaking if the dialog is not closed with the close() function that does the cleanup.

That said, enabling web + {N} scenarios is a top priority. Can you please share why 'ModalDialogParams' are a problem? Maybe we can provide web-compatible stub(#523) for those too?

[NathanWalker]

@vakrilov I like having those services remain Injectable as it does help with sharing code and being able to provide/swap those at runtime so not sure converting some to purely static services would be beneficial for that effort.

I tried all these combos:

// shared
export const MODAL_PARAMS: OpaqueToken = new OpaqueToken('ModalParams');

// {N} root module
1. { provide: MODAL_PARAMS, useValue: ModalDialogParams }
2. { provide: MODAL_PARAMS, useClass: ModalDialogParams }
3. { provide: MODAL_PARAMS, useFactory: () => return ModalDialogParams }

// component
constructor(@Inject(MODAL_PARAMS) private modalParams: any) {}

None of those worked to successfully tokenize modal params :( Other services are able to be tokenized like that to share across single codebase but since you construct ModalDialogParams inside the service const modalParams = new ModalDialogParams(options.context, closeCallback); it causes an issue I believe?

[vakrilov]

You are right - for each dialog - a new instance of ModalDialogParams is constructed, because the context and the close callback are different.

You might to try to map the MODAL_PARAMS token to the existing ModalDialogParams with the following provider: { provide: MODAL_PARAMS, useExisting: ModalDialogParams}. However, I'm not sure if this will work, as you are registering the provider in the root module's injector and the actual ModalDialogParams provider is registered in the injector created for the modal dialog component (which is deeper in the injector tree).

I'm still wondering on what the best way to implement web compatibility is. Do you think it is reasonable to expose OpaqueTokens from nativescript-angular for the services listed in #523 so that they can be provided for web project - without having to deal with nativescript-specific types?

[codeback]

Hi @vakrilov and @NathanWalker,

I know this issue is very old but I'm having problems in getting ModalDialogParams tokenized to integrate it in a Web + {N} application.

Is there any news on this issue? Thank you very much.

[vakrilov]

We haven't done any work on this one yet, but we can kick off the discussion once again.
Can you please share a bit more on what you imagine the final result should be - how would you consume the ModalDialogParams in a web context?

[codeback]

Hi @vakrilov,

Thank you for your response. I've just managed to make this work using another approach. I' ve created two files (services) 'dialog-params.service.tns.ts' and 'dialog-params.service.ts':

// dialog-params.service.tns.ts
export { ModalDialogParams } from 'nativescript-angular/directives/dialogs';

// dialog-params.service.ts
import { Injectable } from '@angular/core';

@Injectable()
export class ModalDialogParams {

  constructor(
    public context: any = {},
    public closeCallback: (...args) => any) {
  }

}

Then, with a gulp task, if I am building {N} app, I rename 'dialog-params.service.tns.ts' to 'dialog-params.service.ts'.

In my custom dialog component I am importing it as follows:

import { Component, OnInit } from '@angular/core';

import { ModalDialogParams } from '../../../shared/core/index';
// import { ModalDialogParams as DialogParams} from 'nativescript-angular/directives/dialogs';

@Component({
  selector: 'app-product-modal',
  moduleId: module.id,
  templateUrl: './product-modal.component.html'
})
export class ProductModal implements OnInit {
  constructor(
    private _params: ModalDialogParams
  ) {}
...

Do you see any drawback in this approach?

[vakrilov]

Looks good to me!
Btw are you using the https://github.com/TeamMaestro/angular-native-seed? It might be a good idea to include this approach to modals in the seed - it looks like a problem many folks using web/mobile shared code will have to face.

[codeback]

Hi @vakrilov,

I am using the angular-seed-advanced (as always, big thanks to @NathanWalker). But yes, the approach I've described above is taken from https://github.com/TeamMaestro/angular-native-seed. They use it to import RouterModule/NativeScriptRouterModule.

[bracco23]

Several months later, I'm still struggling with having a shared {N} + web project work on dialogs. My approach has been to hide the opening code inside a duplicated service, but I'm having trouble trying to get things to work without duplicating component code too.

For reference, my two services, modalForm.service.tns.ts:

import { Injectable, ViewContainerRef } from "@angular/core";
import { ModalDialogService, ModalDialogOptions } from "nativescript-angular/modal-dialog";
import { ModalFormComponent } from "./modalForm.component";
import { Measurement } from "../model";
import { Observable, from } from "rxjs";


@Injectable()
export class ModalFormProvider{
    
    constructor(private _modalService: ModalDialogService){
    }

    open(viewRef: ViewContainerRef): Observable<Measurement>{
        const options: ModalDialogOptions = {
            viewContainerRef: viewRef,
            fullscreen: false,
            context: {}
        };
        return from(this._modalService.showModal(ModalFormComponent, options))
    }
}

and modalForm.service.ts (I'm using @angular/material on web side)

import { Injectable, ViewContainerRef } from "@angular/core";
import { MatDialog, MatDialogConfig } from "@angular/material";
import { ModalFormComponent } from "./modalForm.component";
import { Measurement } from "weight-stats-common";
import { Observable } from "rxjs";

@Injectable()
export class ModalFormProvider{
    constructor(private diag: MatDialog){

    }

    open(viewRef: ViewContainerRef): Observable<Measurement>{
        let temp = this.diag.open<ModalFormComponent, any, Measurement>(ModalFormComponent, {
            viewContainerRef: viewRef
        })
        return temp.afterClosed();
    }
}

Since I have to inject for both sides parameters, I've been trying with a custom InjectionToken and different providers on both sides, but it doesn't seem to work. On web side I can use MatDialogRef from the service side to obtain the instance of the component and to manually close the dialog, if something similar could be done on {N} side I could just manually inject a callback and when it gets called the service could close the dialog manually.

[bracco23]

For future reference, I made it working with something similar to @codeback solution. What I did was basically:

1. Set up a service to open the dialog. The service is duplicated in a web version and a {N} version.

modalForm.service.tns.ts

import { Injectable, ViewContainerRef } from "@angular/core";
import { ModalDialogService, ModalDialogOptions } from "nativescript-angular/modal-dialog";
import { ModalFormComponent } from "./modalForm.component";
import { Measurement } from "../model";
import { Observable, from } from "rxjs";

@Injectable()
export class ModalFormProvider{
    
    constructor(private _modalService: ModalDialogService){
    }

    open(viewRef: ViewContainerRef): Observable<Measurement>{
        const options: ModalDialogOptions = {
            viewContainerRef: viewRef,
            fullscreen: false,
            context: {}
        };
        return from(this._modalService.showModal(ModalFormComponent, options))
    }
}

modalForm.service.ts

import { Injectable, ViewContainerRef } from "@angular/core";
import { MatDialog, MatDialogConfig, MatDialogRef } from "@angular/material";
import { ModalFormComponent } from "./modalForm.component";
import { Measurement } from "weight-stats-common";
import { Observable } from "rxjs";
import { DIALOG_ID } from "./modalForm.params";

@Injectable()
export class ModalFormProvider{
    constructor(private diag: MatDialog){

    }

    open(viewRef: ViewContainerRef): Observable<Measurement>{
        let temp = this.diag.open<ModalFormComponent, any, Measurement>(ModalFormComponent, {
            viewContainerRef: viewRef,
            id: DIALOG_ID
        })
        return temp.afterClosed();
    }
}

I make sure to set a known ID to the dialog when opened with MatDialog, this step is important.

2. Create a stub ModalDialogParams for the web version. So I have:

modalForm.params.tns.ts

export { ModalDialogParams } from "nativescript-angular/modal-dialog";

modalForm.params.ts

import { Injectable } from '@angular/core'
import { MatDialogRef, MatDialog } from '@angular/material/dialog';

export const DIALOG_ID: string = 'form_dialog';

@Injectable()
export class ModalDialogParams{
    constructor(private dialogs: MatDialog){
    }

    closeCallback(data?:any){
        this.dialogs.getDialogById(DIALOG_ID).close(data);
    }
}

On {N} I export the already present ModalDialogParams, while on web I create a custom version, added to the providers list on my web module, which uses the MatDialog service and the known ID to retrieve the MatDialogRef and invoke close.

3. On my component, which is not duplicated:

modalForm.component.ts

import { Component, OnInit, ViewChild } from "@angular/core";
import { ModalDialogParams } from "./modalForm.params";

@Component({
    moduleId: module.id,
    selector: "modalForm",
    templateUrl: 'modalForm.component.html',
    styleUrls: ['modalForm.component.css']
})
export class ModalFormComponent implements OnInit {

    @ViewChild('formView') form: any;
    measurement: Measurement;

    constructor(private _params: ModalDialogParams) { }

    ngOnInit() {
    }

    onClose() {
        this._params.closeCallback("prova");
    }
}

Now when I invoke closeCallback the right chain of events is started and things are done as they should. I am using it in my repo https://github.com/bracco23/weight-stats-frontend/commit/a58287bd450a02afdf6e350efb081770c210042d