Modal: string argument to the open method is confusing
See original GitHub issueSee http://stackoverflow.com/q/39464345/1418796
Really, the string argument is only good for unit-testing but not for any real-life applications. We should remove it altogether or at least clarify in the docs.
On top of this we need to support components as arguments to the open
method, see #680
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Best practice for calling the NgbModal open method
The string -typed argument is not very interesting - in fact it was mostly added to aid debugging / unit-testing. By using it...
Read more >Value of a parameter in the query string causes a new page to ...
I want to use this value as the parameter (with a different name) in a link to open a modal dialog box. $('#my-element').after(' ......
Read more >Modal · Issue #3 · ng-bootstrap/ng-bootstrap - GitHub
One approach to explore would be to allow passing component types as argument to the open method. And in this case we could...
Read more >showModalDialog method (Internet Explorer) - Microsoft Learn
Creates a modal dialog box that displays the specified HTML document. Syntax. var retval = window.showModalDialog(dialog, varArgIn, varOptions); ...
Read more >views.open method - Slack API
Open a modal with a user by exchanging a trigger_id received from another interaction. See the modals documentation to learn how to obtain...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
My vote would go on removing the string argument completely, as it’s just utterly confusing. Adding the component support to the
open
method makes a lot of sense. This will take out quite some boileplate code that is now needed to support the usecase of #680How about something like
where the component is passed the
modal
instance as an@input
?to avoid having to specify
@Input
it could also be possible to subclass aModalComponent
:where
ModalComponent
is something like: