fix: handle indices properly when cellAlign is center or right

[fritz-c]

Description

There are a variety of intertwined bugs related to slide index bounds (what the dots correspond to, also what determines whether prev/next buttons should be disabled) caused when cellAlign and scrollMode are thrown into the mix.

1. With autoplayReverse set to true and cellAlign set to something other than left, the component starts with an odd offset: issue repro. Note how the rightmost slide, which we should presumably start from, is partially concealed, and we cannot click the button to move over to it.

2. Autoplay does not go to the last slide with cellAlign of center: issue repro

3. Scrolling to the right, we cannot reach slide 4: issue repro

This PR fixes the above, as well as performs a bit of generic refactoring.

NOTE: the fixes change some scrollMode="remainder"-like behaviors that were baked-in before. For example, this demo disables the "NEXT" button once the sixth slide is in view (e.g., slideIndex = 4).
With the fixes in this PR, the same scenario (demo from PR preview) would see the "NEXT" button enabled at that point, so the user could click again, resulting in slide 6 on the left side and whitespace on the right.
This could be seen as a breaking change. I tend to see it as making the component more closely follow the behavior that the component props defines. Setting scrollMode="remainder" will produce the same result that was baked-in before, if that is what is desired.
This change reduces the assumptions we are making about the library user's use case. For example, without the fix, the current-slide class will never be assigned to the final slide in the scenario above, whereas it can be assigned with the fix in place. This change was omitted, as the flexibility with current-slide I pitched here didn't really make sense when you were jumping two slides at a time (=skipping every other slide) anyway. Also, it seemed like a bit of a trap that you could have three slides shown per page with a collection of 9 slides, and still end up with 4 pages.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

A variety of unit tests appearing in the PR, and manually

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
nuka-carousel	✅ Ready (Inspect)	Visit Preview	Aug 9, 2022 at 5:02PM (UTC)

[fritz-c]

This modification corresponds to the change in behavior in the scenario laid out in the PR description.

[fritz-c]

Cypress will wait for animations to finish, so the cy.waits are unnecessary:
https://docs.cypress.io/guides/core-concepts/interacting-with-elements#Animations

[fritz-c]

Regarding the changes in starting index for right-aligned stories:
When working with scrollMode="page"+cellAlign="left", this library prevents scrolling once all slides are reachable. So a carousel with 9 slides and slidesToShow={3} will only have three navigation dots, one for each "page", corresponding to indices [0, 3, 6].
With the identical case, but flipped around via cellAlign="right", we need to start from index 2 to similarly minimize unnecessary pages, for a result of [2, 5, 8]. Essentially, the algorithm to generate such an array works from the tail end of the slides, at slideCount - 1, moving towards the front until all slides have been reached.

This has the effect of creating some potentially puzzling offsets if you start from the leftmost end of the carousel, as is default.
e.g.,

But when using the carousel from right-to-left, whether it be with autoplayReverse on or by setting slideIndex to the last slide initially, this initial index makes perfect sense.

[gksander]

Awesome!!!