-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(carousel): add event on carousel slide with direction info #1406
feat(carousel): add event on carousel slide with direction info #1406
Conversation
b73773e
to
11a2818
Compare
a654011
to
933d037
Compare
Don't understand why the build fails...in local it works |
*/ | ||
export enum NgbSlideCarouselEventDirection { | ||
LEFT = <any>'left', | ||
RIGHT = <any>'right' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why type these to any
and not make use of the implicit string typing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, you cannot assign directly a string to an enum value. In fact if I remove , typescript says: type string is no assignable to type NgbSlideCarouselEventDirection.
Is there another way to do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you should just be able to do
export enum NgbSlideCarouselEventDirection {
left,
right
}
and use it like NgbSlideCarouselEventDirection.left
to represent the string value left
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but doing like this, NgbSlideCarouselEventDirection.left and NgbSlideCarouselEventDirection.right values won't be 0 and 1 instead of 'left' and 'right'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using an union type on the variable ('left' | 'right'
) instead of an enum ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be easier to use as an enum instead of strings. I was imaging using it from outside and doing something:
event.direction === NgbSlideCarouselEventDirection.LEFT
instead of
event.direction === 'left'
The build failure is some flakiness with Edge testing in Sauce Labs - that is to be looked into. This PR looks mostly good to me. |
src/carousel/carousel.ts
Outdated
this.onCarouselSlide.emit({ | ||
type: 'slide', | ||
prevSlideId: this.activeId, | ||
newSlideId: selectedSlide.id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe these can be shortened to prev
and current
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree. I will change them. Thanks for the suggestion :)
933d037
to
3973084
Compare
const currentActiveSlideIdx = this._getSlideIdxById(currentActiveSlideId); | ||
const nextActiveSlideIdx = this._getSlideIdxById(nextActiveSlideId); | ||
|
||
return currentActiveSlideIdx > nextActiveSlideIdx ? NgbSlideCarouselEventDirection.RIGHT : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect that when you are on the first slide and click the back arrow that the direction would be RIGHT. However, when you are on the first slide with this logic it will always return LEFT, regardless of which direction you are moving in. The same thing applies if you are on the last slide, the direction will always be RIGHT, regardless of which direction you move in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are totally right! Thanks a lot!
I have just updated my PR. Now the logic is simpler, basically when you click on prev is always RIGHT and when you click on next is always LEFT. The computation based on the index is now done only clicking on the indicators.
3973084
to
a483b45
Compare
src/carousel/carousel.ts
Outdated
@@ -43,7 +45,7 @@ export class NgbSlide { | |||
}, | |||
template: ` | |||
<ol class="carousel-indicators"> | |||
<li *ngFor="let slide of slides" [id]="slide.id" [class.active]="slide.id === activeId" (click)="cycleToSelected(slide.id)"></li> | |||
<li *ngFor="let slide of slides" [id]="slide.id" [class.active]="slide.id === activeId" (click)="select(slide.id)"></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes the behaviour in subtle way: now we would reset timer on click. Was it intentional? If so we should add a test for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no it comes from the rebase. I am sorry, I will revert it. Let me know if you want to revert the package json as well and I will update my PR. Thanks for the review
src/carousel/carousel.ts
Outdated
* A carousel slide event fired when the slide transition is completed. | ||
* See NgbSlideCarouselEvent for payload details | ||
*/ | ||
@Output() onCarouselSlide = new EventEmitter<NgbSlideCarouselEvent>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we name it just slide
? We are in the carousel context so no need to add the Carousel
in the name. Similarly we know that this is an event so no need for on
(we are not adding it for other directives / events).
package.json
Outdated
"@angular/common": "2.3.1", | ||
"@angular/core": "2.3.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change? While it doesn't hurt it always best idea to avoid unrelated changes in a single PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, this has been moved automatically by yarn when I did the update. It was not in alphabetical order. I can revert it if you prefer, no problem.
@@ -8,6 +8,7 @@ import {DEMO_SNIPPETS} from './demos'; | |||
<ngbd-api-docs directive="NgbCarousel"></ngbd-api-docs> | |||
<ngbd-api-docs directive="NgbSlide"></ngbd-api-docs> | |||
<ngbd-api-docs-config type="NgbCarouselConfig"></ngbd-api-docs-config> | |||
<ngbd-api-docs-class type="NgbSlideCarouselEvent"></ngbd-api-docs-class> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this new functionality warrants a separate demo - 2 carousel side by side already look wired on our demo page so I would prefer adding more demos unless those really add a lot of value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it the way to update the documentation adding specific information about this new event?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation is generated automatically from the source code - as long as you've got JS doc on the @Output
it will make it to the demo site.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@giampierobono thnx, it looks good generally speaking but I've left some comments that I would love to see addressed before we merge this one. Thnx again! |
cdbee4d
to
940b069
Compare
@giampierobono are you planning to do further work on this PR? If so could you please remove the demo part and address all the remaining comments so I could merge this PR? Thnx! |
940b069
to
3fd6a6d
Compare
@pkozlowski-opensource I have just reverted the demo changes and I have already applied all the other changes in comments. I was waiting for your reply to my comment about the documentation. The PR should be ok now. Let me know if something is still missing. Thanks again. |
3fd6a6d
to
305091e
Compare
src/carousel/carousel.ts
Outdated
/** | ||
* Event type | ||
*/ | ||
type: 'slide'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need type
? Do we have other types and we need to distinguish between those? Isn't interface enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I have done this the first time, I have checked the bootstrap carousel doc and there are 2 events: slide and slid (the first is for transition start and the second for transition end if I remember correctly) and the initial plan was to reproduce the same behavior, that's why we have type.
Need to add the slid event but I had not time till now (don't even know if it's really needed), so I have pushed this. I can remove it if you want, I agree that since by now there is only one event it's not necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeh, let's remove it. We should rather have 2 different event interfaces rather than trying to discriminate those by a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of course 2 different events and not only one discriminated by strings :) it's the bs event structure having the 'type' prop so I have reproduced it. I am going to update the PR
305091e
to
b9d8374
Compare
b9d8374
to
8422200
Compare
@giampierobono I was about to merge this PR but then I had a closer look and started to ask myself the following question: what is the use-case for exposing slide direction in the new event? Do you have a specific need? AFAIK it wasn't explicitly asked for in any of the prior issues (#1331, #1356). If you don't have specific use-case I would prefer that we leave off this functionality as it adds a bit of code and currently people can't even visually see slide direction as we don't support animations (!) |
@pkozlowski-opensource sorry I have just seen your message. For me one use-case is keep in sync the carousel and some panels below it (with text adding more details to each carousel image), that will be displayed or not, following the event direction without relying only on the image id. Or another use case could be bind to the event and perform an action only if the direction is "right" or "left" and not both. |
@giampierobono sure, I can also imagine use cases - I was rather asking if you, or any users that you know, already has a specific use-case :-) |
Ah ok :) For something I am working on, the second use-case is exactly what I would need...would be nice to have it. |
Is something still blocking this pull from being merged? |
Is there further work on this PR before it get's merged in? I have a couple of use-cases that this would be greatly helpful for. Thanks! |
Before submitting a pull request, please make sure you have at least performed the following: