You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request
Current behavior
At the moment (version 8), a few events (close, show, firstImage, ...) are available to hook on the different processes of the library, but they are partial and do not allow certain manipulations.
Expected behavior
Most of the events are triggered AFTER or BEFORE a process, but rarely both events exist for one process. Having both per process would allow a large panel of manipulations.
Following events would be especially useful:
afterClose - right after the modal view closes
afterShow - right after the modal image is visible
beforePreviewsChange - right before the previews will be updated
afterPreviewsChange - right after the previews have been updated
What is the motivation / use case for changing the behavior?
That would complete the sets of already existing events, allowing even more scenarios. If it was easy to implement, that would be a nice upgrade!
My usecase is to hack the rendering of previews (as long as custom templates are not available), for which 'show' is very useful, but I then have to rely on an arbitrary setTimeout to add modifications when the image and the previews are rendered.
Environment (the most important section to fill very carefully)
- @ks89/angular-modal-gallery version: 7.2.5
- Node version: 14.15.0
- npm version: 6.14.8
- Operating System and version: Windows 10
- Angular version: 11.2.0
- angular-cli version: 11.2.4
By the way, great job here!
And very efficient. I was jauging different libraries to handle numerous images (several thousands), and this one is lightning fast!
The text was updated successfully, but these errors were encountered:
Thank you for your interest in this project and for your feedbacks. They are very important to improve the library.
If I remember correctly the 'aftershow' event was already on schedule, but I removed it, because it caused some troubles. I really don't remember why and when. It needs a new experimentation.
The afterClose was another event that caused me some troubles, because if I remember you must be sure that the library still exists when you trigger the event, instead the close event is something that close (destroy) the library itself. Implementing this in a cleaner way without breaking something could be challenging. It need some investigation.
Events on previews seems a nice to have feature for sure, because at the moment I completely ignored this scenario.
The next release of the library will be version 9.0.0 (already implemented at 90%), ASAP after angular 13 stable release (probably in a couple of months). Version 10 will be the right version to improve some features like, previews (both for modal and carousel) and why not also events.
Feel free to help me with pull request, but please start from branch 900. Version 7.x.x is deprecated and not maintained.
I'm submitting a...
Current behavior
At the moment (version 8), a few events (close, show, firstImage, ...) are available to hook on the different processes of the library, but they are partial and do not allow certain manipulations.
Expected behavior
Most of the events are triggered AFTER or BEFORE a process, but rarely both events exist for one process. Having both per process would allow a large panel of manipulations.
Following events would be especially useful:
What is the motivation / use case for changing the behavior?
That would complete the sets of already existing events, allowing even more scenarios. If it was easy to implement, that would be a nice upgrade!
My usecase is to hack the rendering of previews (as long as custom templates are not available), for which 'show' is very useful, but I then have to rely on an arbitrary setTimeout to add modifications when the image and the previews are rendered.
Environment (the most important section to fill very carefully)
By the way, great job here!
And very efficient. I was jauging different libraries to handle numerous images (several thousands), and this one is lightning fast!
The text was updated successfully, but these errors were encountered: