Broken scrolling behavior after removing all & adding the slides if append <= perPage items

[WhereJuly]

Hi,

I found the strange effect after removing all slides and appending the new slides in case the number of appended slides is less or equal to the perPage setting. The scrolling stops responding normally and the slider becomes non-usable.

Here is the codepen example

Can you have a look?

[WhereJuly]

@pawelgrzybek
Hi Pawel,

a couple of thoughts on the code if you do not mind apart from the scrolling issue.

1. Aren't touch/mouse down/up/move 6 separate handlers can be unified to only 3? The pairs are nearly identical. This would be (nearly) 2 times less code. Nothing stands in the way to make only two, say, downEventHandler, upEventHandler, moveEventHandler. The small differences can be easily solved with ternary operators or one-liner ifs.

   And here is the questions: is this.drag.startY really needed? You use it only twice to save and compare the vertical movement. As the slider goes only horizontally, is the vertical movement redundant?

2. The additional options: I sign under the smallest possible & efficient code base statement.

   Nevertheless if people like your slider & request the new options, no reason to reject the really valuable ones. The solution could be to make the extended version. This would require the existing core module and the other extesion module with additional methods being built happily by Webpack into 2 production versions, the core and the extended one.

   This does not mean to put all the options people are asking for into extended part. Only the ones really demanded and not solved by a user's own JS/CSS/HTML. Like e.g. autoHeight.

   This way you would not restrict Siema from development in a broader sense. And this would allowed for a broader audience for Siema.

[pawelgrzybek]

Hi.

Thanks for your contribution.

1. There are some differences between mouse down/up/move and key down/up on the handlers. Unfortunately they cannot be merged — I tried hard. Pointerevents is looking like a solution, but we are not ready yet (browser support). More about pointer events here:

https://pawelgrzybek.com/whats-the-deal-with-the-pointer-events-in-javascript/

The this.drag.startY is important because I use it to detect the distance of vertical / horizontal scroll and this factor decides if the scrolling is blocked or not and the swiping is enabled or not on a carousel.

2. Yes and no :) I totally agree with you about adding requested features to the lib core. The thing is that everything needs to go into particular direction. If you are building a full carousel solution that suits all needs — go for it. If you are building a tiny little lib that actually doesn't do anything apart from a bit of math and exposing a clean API — you decide where the border between "core feature" and "nice to have" is. By the way — autoHeight is coming :)

Thanks a lot!

[WhereJuly]

Hey Pawel,
points taken. Interesting article:) I am glad if that was of any help.