Implementing a Slider Component While Getting CSS Positioning Right
You have innumerable amount of use cases for slider buttons. You might have a photo gallery or car parts or colors to show. That will allow your users to explore your content.
Is it hard to implement slider buttons, then? Not really, however, there are some subtleties of CSS you need to be aware of. Applying a CSS rule on element-A and getting side-effects from element-B can be confusing or frustrating. You will learn what unintended side-effects you may encounter when you implement your own slider buttons and how to tackle them.
It is helpful if you have an understanding of TS, Nextjs, Sass and MaterialUI to follow along. If you unfamiliar with that stack, but you’re proficient enough know what closures are in JS, then you still got this 😉
For the rest of our journey, let’s assume that we have a paint shop and display to our customers 10 beautiful colors we have in our inventory. How do we start?
One way that might come to mind first is to use fixed positioning because we want those buttons to be fixed, right? Well, this doesn’t function as expected though. Then, we make a small improvement by using absolute positioning, but that doesn’t quite make the cut either. There will be still a missing piece. Let’s find it out!
TLDR; if you just want to see the correct implementation, jump to the Absolute Positioning with HTML Correction.
You can also see the code in this repository.
I suggest that you check out the result of those three implementations before going forward. Click here to take a look.
There are a couple of functions and components that we need to know what they do before going forward.
We have also two custom components that are
RightSliderButton. You will see their code and explanation below so for now just assume that they are two cool buttons that work like a charm.
There is also this function
get10RandomColors that gives us, surprise surprise 🥳, 10 random colors.
Now, let’s start examining above implementation, shall we? In CSS, the container is positioned relative and slider buttons are fixed. The distance from right and left is zero for the right and left button, respectively. In HTML, we placed the colours between the buttons.
You want to place slider buttons on both sides of the container and they shouldn’t move with the content. That sounds like fixed, doesn’t it? Well, fixed elements have their reference to the viewport so they stay at the same position even though the container scrolls up or down. Check out the first example here.
Even if you scroll up and down the page, the buttons still appear on the same spot with respect to the window. You want to see those buttons only in the relevant component, though, so using a fixed position is not the solution we are after.
In this step, we take a look at absolute positioning. At the end of the day, we want those buttons to reference their parents when deciding their positions and not the page.
When we hot-reload our project, then it seems to have worked in the first sight because the buttons are in the parent container. That is a step in the right direction!
Oh, wait… when you click on the right slider button, then it moves with the content to the left. We don’t want our buttons to move, do we? Because otherwise how will you actually move to the left when you don’t have a left slider button on the screen anymore 😱
Absolute Positioning with HTML Correction
Well it turns out our solution is to go from CSS to HTML. We put the buttons one level higher in HTML. That way, the callback functions of slider buttons are still handling the movement but they themselves are not part of the scrolling area.
You can easily put those buttons on both sides of scrollable area with CSS properties
Let’s continue with our slider buttons and I’ll show you the magic happens as promised.
These two buttons have a lot in common and in fact, all the difference can be reduced to a boolean value. That’s why we create one functional component with only two props. These tell us whether the current button should slide to the right or to the left and also to which implementation it belongs as we examine three different implementations.
Everything in the above snippet should be easy to understand apart from the first a couple of lines in the
sliderHandler. It would have been actually also very easy, but we need to differentiate which of the 3 implementations we are sliding for.
parentSliderWrapperAddress gives us a reference which we can find the parent container with. The
isItSiblingImplementation tells us whether we are sliding for our last and correct implementation where we have the scrollable area as a sibling element. The first if-else finds the scrollable area and the second if-else slides that area if it is found.
Helper Functions for Colors
Lastly, let’s take look how we generated colors. They are mocked since we don’t really have an inventory, unfortunately. First, we create a function that produces colors and it might look something like this:
Keep coding. Keep breaking. Keep improving.
That is all. For today.