DEV Community: Martin Wheeler

Creating A Horizontal Scrolling Web Page. Bonus: With Parallax!

Martin Wheeler — Tue, 06 Oct 2020 17:32:19 +0000

Introduction

Hi all! I just want to say, before you delve in, that this really is a hard-and-fast explanation of how this is put together. Over the coming days I'm looking to revisit this with a video tutorial, including a more detailed explanation and a start-to-finish approach of how it's made. In the meantime though, I still wanted to share this in the hope that somebody may find it useful.

I was recently inspired by a portfolio website I discovered for a designer and developer named Joseph Berry. His website, aside from being both modern and beautiful, really got me interested in the idea of horizontal scrolling.

Horizontal scrolling has become somewhat of a trend on the web and, in my opinion, it is particularly good at building websites that want to convey a story - this is most likely due to its likeness to the way we scroll through a book. I also think it’s a nice surprise for a user when they expect to scroll down but, instead, the screen scrolls right.

Jumping through the code of Mr Berry’s site also got me thinking about something else. Could I do this in CSS alone? I’ve been really intrigued lately by the philosophy of progressive enhancement and seeing what can be done with the browser’s most reliable tools, HTML and CSS. Let’s see what we can come up with.

I knew off the bat there were a number things I probably wouldn’t be able to achieve with CSS alone, but that’s OK. Let’s focus on what we can do. If you’ve had a look at the website, you’ll see that there are two key visual effects - the horizontal scrolling, and the parallax effect. These are what we’ll be looking at here.

This is what we'll be making:

Let's Dive Right In

We’ll start with the HTML.

This is all we need in our HTML to achieve what we need. Let's break down what's happening.

The <main class="viewport"> element will be home to everything horizontal. Whilst this element isn't strictly necessary, as you could use the body tag to the same result, using it will allow us to adjust the horizontal scrolling area down the line and allow us to more easily add other semantic HTML like a header and footer.

Following this we have our parallax-parent element which, unsurprisingly, will be the container for anything we want to apply perspective to. There's a background-colors element for our background, and some parallax-child-containers which will house our pages/content.

The CSS

Our CSS isn't quite so straightforward, but it's also nothing mind-bending. The key to this entire setup is essentially one magical, almost limitless, CSS property - the transform property.

I've started with some basic style-resets and also, having written this is SCSS, a couple of useful variables. We'll see shortly exactly how these will be used.

You can, of course, create this is vanilla CSS and simply hard-code these values.

The below code is all that's needed to style our viewport element.

This simply ensures that our element takes up 100% of the available screen-space, and doesn't allow for any scrollbars to appear should the content exceed this size - which it will.

Our parallax-parent element is what will allow us to achieve the cool 3D effect found on many modern websites. You know the one - where one element moves a bit faster than the other, giving the illusion of them being closer and farther away respectively. We do this by applying perspective: 3px to the element and setting it's perspective-origin.

The default value of perspective-origin is actually what you see above (50% 50% 0) so there's no need to code this in. I put it there originally so I could play around with the values, so I've left it there in case you want to do the same.

The parallax-parent also doubles up in one extremely important way, leading me to think later that maybe parallax-parent wasn't the best naming for this element. It's this element which actually does the thing you came here for.

Check out line 8 of the code - transform: rotate(-90deg);. This element is actually being rotated anti-clockwise so that it's top is it's left, it's left is it's bottom, it's...well, so on and so on.

We've also set the transform-origin: top left; which means that the rotation will happen around the top left corner. Let me explain with a diagram.

This blue rectangle represents our parallax-parent - in this case being displayed on something like a desktop screen. In the top left corner you'll notice a red circle. This is our transform-origin.

So now, when we rotate this counter-clockwise by 90 degrees, or rotate(-90deg) as CSS would have it, this is the point at which the rotation will occur.

And what does that look like? Well, on your screen, it will look like your element vanished! Why is that?

Well, our element has rotated its way out of the viewport and, therefor, can no longer be seen. This is where our use of top: $height (or top: 100vh for CSS) comes in to help us out to return the element back into view. You'll also note that our height is set as $width and our width is set as $height. This now adjusts our element to fit nicely back into the viewport like it was before, only this time rotated -90 degrees.

This has now become a very important point moving forward, as how we deal with top, bottom, left, and right in CSS with our absolute positioned elements has been affected...and it can be somewhat confusing at first.

Lastly you'll notice that ::-webkit-scrollbar has been used to hide the scrollbar in our element. An important note here is that this selector is not a web standard and will have different outcomes on different browsers, so be careful.

From the MDN docs:

::-webkit-scrollbar is only available in Blink- and WebKit-based browsers (e.g., Chrome, Edge, Opera, Safari, all browsers on iOS, and others).

Our background-colors element incorporates a simple CSS gradient to mimic a colour change as the user scrolls. In the example website I pointed to at the beginning of the post the developer uses JavaScript to change the colour dynamically, most likely with scroll event listeners. As we said we would be using plain S/CSS only, we'll stick with a gradient.

The element has been sized to cover $width * $pages (or 100vw * 3 = 300vw) and can be resized as necessary. Bare in mind, using this approach, if you want each page to have its own colour you will need to adjust the gradient accordingly.

The parallax-child-container element uses much of the same styling with regards to sizing as its parent element, the parallax-parent, with the width and height still being "reversed". Here I've used a SCSS function to iterate over the elements and apply a top equivalent to the nth-of-type - 1 * $width. Essentially this gives the first element a top: 0, the second a top: 100vw, the third a top: 200vw, and so on. AGain, you could easily hard code this into the CSS as even with the SCSS we need to know how many elements (or $pages) we have for the function to work.

Now, all of our "pages" take up a full-screen each, much like in the example portfolio or Joseph's.

The parallax-child element is where we start to return back to "vertical viewing". Let's look at the different transforms we're using on this element.

To keep the element central within its parent, we apply a value 50% to both top and left, and -50% to both translateX and translateY. We also apply rotate(90deg) to bring everything back to "normal", visually speaking. Again, the default values for transform-origin have been left so there's no need to keep these should you be happy with them.

Finally, our z axis gets some love! By applying translateZ(-1px) we see a shift "backwards" in our elements position. And, when we scroll, we notice that the element scrolls a little more slowly than before. It's very subtle, but noticeable if you focus on the gradient. If you're working against a plain background, you likely wouldn't apply this transform to these elements.

Lastly, we apply similar styling to the parallax-background, only this time we push it "back" much further at -8px.

You may have noticed that when we apply a value to translateZ, we also apply a value to scale. There is a useful write-up by Google explaining this in more detail and why this is done, but essentially it negates the resizing that takes place when we "push" or "pull" our elements backwards or forwards respectively. Imagine driving further away from a building, it get's smaller, right? The only way to make it seem the same size it was before, without driving back, is to scale it up. Voila!

Lastly, we size the background to cover the number of pages we have, in this case 3. Once we've applied some styling to the header nested in parallax-background we're done!

I hope I was able to share something interesting with you here, and I’d really appreciate any feedback on either the content or the writing. I’d like to do this more often and making it worthwhile would be a massive bonus.

You can find the sourcecode for this project on Github.

Create A React Search Bar That Highlights Your Results

Martin Wheeler — Thu, 24 Sep 2020 12:03:53 +0000

Introduction

Sometimes it's fun to put the big projects aside for a while and make something small. That's not to say it can't be challenging - it's most of the time during these small endeavours that I find myself learning something new that I may have been putting off for a while. This is the joy of not having the distraction of scores of components, state, props and more.

For no specific reason, I was inspired to make a dynamic search bar which does three things:

Takes a text input
Filters the results containing said text
Highlighting that very text

I'd made something similar to this a long time ago in vanilla JS, but I don't remember how exactly (and chances are I won't want to).

However, it was something I hadn't needed up until now in a React project so I thought it would be a good use of time in case, you know, the time ever comes.

Tools For The Job

Being the "bish-bash-bosh" project this was I stuck with React and React alone. OK, there's obviously some styling, but nothing more than a few imported Material UI components. This really was more about the functionality then anything else.

We will also be making use of some JSON placeholder from this JSONplaceholder website to populate our app. We're pulling from the following API:

This will deliver back to us an array of objects, each like so:

Getting It Done

The file structure for this project is as follows:

Let's go through the components before diving into App.js, where the bulk of our logic sits, so we can gain an understanding of what's going on in each.

Let's take a look at Item.js.

Before we move on, I just want to point out that Card, CardContent, Typography, and classes.* are all related to Material UI and not important to what's going on. You can think of them as almost any HTML element you like.

With that aside, let's look at what is important.

Well, if we were to look at this without all of the additional styling or function we would have something like this.

So, for the most part, this component is essentially our container for each of our objects we receive back from our JSON placeholder API. These values are being passed into the component via props and rendered as we choose.

We'll come back to the slightly more complex version once we've look over the rest of our components.

SearchBar.js is an even more compact component. Beautiful!

Again, please note that the Textfield element is a Material UI component, and could just as easily be an input element with the type="text" attribute.

The only prop that is passed to this component is via props.onInput, which is responsible for updating our state each time a new character is typed into or deleted from our input field.

Our last component is Counter.js. This component isn't strictly required to make this project work, however I thought it was a nice touch.

You know the deal with the Material UI stuff by now!

Only one prop this time. We're simple passing in a result, and we'll come back to exactly what that is very soon.

OK, it's time for the big one. Let's move on to App.js. For the sake of readability we'll break this down into smaller sections as it's a fair bit larger than the previous components. Not humongous, but bigger nonetheless.

This part of the app makes use of the useEffect and useReducer hooks provided natively with ReactJS, so we'll start by importing those. We then bring in our 3 components we just went through to complete our imports.

A Note On useReducer

As the functionality for this project was all crammed into the App component, I decided to opt for useReducer over useState to save from having four separate state variables, though it could just as well have been implemented that way too.

If you're familiar with useReducer you can skip along to the Continuing With The App section. Just take note of the code above and the coming snippets.

We start by declaring our initialState for the component which consists of four different keys - so what are they for?

isLoading accepts a boolean value to essentially let our app know whether the async function has completed or not - or is loading.
data will be our store for the array we receive back from our API call.
search will hold the string which is entered into the SearchBar component.
searchData will be a filtered version of our data state array. This will remain an empty array until something is entered into the search input.

Our reducer function is the tool we use to alter or update our state object as necessary. A note here, you should declare both your initialState object and reducer function outside of the component itself. If you are familiar with how useState works then you're in a good position to understand useReducer as the two are very similar. I'll explain how.

I mentioned before that this could have just as easily been implemented with useState over useReducer, and here's an example of how the two compare. Both of the code examples below have one thing in common - in the useReducer example the dataTwo and isLoading key/values are able to hold the exact same information as the dataOne and isLoading variables in the useState example. This comes as no surprise as this is plain JavaScript. The difference between them comes in how the state is updated.

With useState we are provided a function, which we name, as a return value from useState(). This function is how we update the value of state, for example setData(data) would update our data state to contain (in this example) the array returned from our API call, and then we could call setIsLoading(false) which would update the isLoading variable from true to false.

With useReducer we need to provide a reducer function (which we did in our code snippet above) to update the state object. This has the added benefit of being able to update multiple states at once. Take a look at case "SET_DATA": in our snippet.

In the return value we start by passing in the initial state using the ES6 spread operator. This essentially ensures we start where we left off and pass all existing state values back into the object we want to return. We then pass in the key/value pair of data: action.payload. This updates the current value of data to the one which we pass in when we call the reducer function (which we'll come to soon). In the same return, we are also able to update isLoading to false to end the loading sequence.

All that's left to do is use the useReducer function like so :

This gives us access, in the same was as useState, to our initalState (and object in this case stored in the state variable) and a function to update our state (in this case stored in dispatch). We pass in our reducer function and intialState and we are ready to go! We can now call dispatch in our component which will fire off our reducer function and update our initialState object:

We need to pass in the "type" of update we wish to be carried out and, where applicable, the "payload" for the update. type is determined in the switch statement of the reducer function, and payload is a fancy word for the data we want to store there (be it an array, boolean, string, etc.) And that's state updated!

Hopefully, you can see how useReducer could be beneficial. As the complexity of your app and its state grow, and the relationship between those states becomes stronger, you will inevitably find that useReducer is superior in handling the growing workload. Of course, you would likely want to incorporate a level of error checking to this but for the sake of this project this was sufficient.

Continuing With The App

Now we've got a home for our state and the ability to update it we can move on to the functionality. I won't go into how the data is fetched from the API, there are a million tutorials, blog posts and docs on that. All that you will want to know is that we use the dispatch example above to get that data into our state.

The return statement for our App component contains our SearchBar, Counter, and Item components. Let's go through each one and start connecting the dots.

We'll start with our SearchBar component and the function that is called within its onInput attribute. As you'll remember, we passed a prop down to this component via props.onInput and this allows us to call the following function when we type something into our text input:

Woah! That's a lot of code for an input. Well, this function does a little more that just deal with the input itself. Let's deal with that first though, and it's a pretty small part of the function.

On the second line of the function we declare a variable str and assign it e.target.value which simply keeps the string as it is entered into the input field. On the following line we call our dispatch function (go back through the A Note On useReducer section if you've no idea what that means) and pass the type of 'SEARCH_INPUT' and payload the value of str. This, together, updates our state to always store the most up-to-date string in the input field.

The next part of the function deals with the filtering of our data array, stored in state.data. We make use of the JavaScript .filter() method to iterate through the title and body values of our objects and see if the text in our str variable is included (using JavaScripts .include() method anywhere in their respective string. The addition of the .toLowerCase() method ensures that no matter what casing we use when we type into the search bar, if the letters themselves match our filtering will be successful. Without this a search for "Hello World" would not return the result "hello world" - and we don't want to be that pedantic with our users!

One of the many great thing about JavaScripts array methods is the ability to chain them together. In this instance, we can then call the .map() method on state.data to iterate though each of the filtered objects and apply our highlighting.

Highlight: The Highlight

This took me a great many attempts to get right, and part of me wishes I could have found a way to do it using only the strings themselves, however I had to call upon the dreaded dangerouslySetInnerHTML to make this work.

At the beginning of this article I showed you the following code:

This is our Item component, and you've likely noticed that two of the elements make use of dangerouslySetInnerHTML to populate themselves. If you want to read more about dangerouslySetInnerHTML then I suggest checking out the official docs. However, we will make the assumption in our case that we trust our source and the content it provides.

The createMarkup function returns an object with the key of __html and value of the HTML itself, as recommended in the React docs, and this value is used to set the inner HTML of each element. This approach turned out to be necessary to be able to inject a <mark> element into the string to function as our highlighter.

We will be making use of JavaScript's .replace() method to highlight our strings, therefore we start by declaring a new variable for the value we will have returned to us by this method. .replace() takes in two arguments, the first of which is the pattern which we want replaced. This could simply be a string or, as is our approach, a RegExp. The RegExp itself takes two arguments - firstly the string (or pattern) we want to identify, and secondly some options (or flags) to give the RegExp some guidance on what we want done. In our case we pass the string "gi". This does two things. The g tells the RegExp that we want to search the entire string and return all matches, and the i that our search should be case-insensitive and without this, like if we were to omit the .toLowerCase() method from our filter, we would not highlight words regardless of their case.

One the has RegExp has identified the characters we would like to replace it moves on to the second argument in the .replace() method, which is the what should replace that. This is where and why our use of dangerouslySetInnerHTML was necessary as we are inserting the <mark> tag back into our object. Without this we would actually render the characters around our string on the screen.

Not pretty.

This second argument is a function with the parameter of match. This allows us to re-purpose our original string, wrap it in the new HTML element, and return it. These new values are now the values stored in the newTitle and newBody variables. We can now simply return these back into the newArr constant in our return statement, being careful not to overwrite our original object values using the spread operator:

The final piece to this function is to dispatch our new array newArr of filtered and highlighted objects into our state.

Now all that's left is to render the results.

This nested ternary operator asks two questions to decide what to do. Firstly, have you finished loading yet? Yes? Right! Then, have you typed anything into the search field (state.search.length > 0 ?)? Yes? In which case, I'll run through everything that's now in state.searchData (including their new title and body values and their <mark> elements you filtered out) and generate your Items for you.

Voila! Would you look at that!

And if there isn't anything in the search bar? Well then, I'll just render everything you have stored in data. This is completely unfiltered and untouched.

But, what happens if I do type something into the search but it doesn't have any matches? Well, typing into SearchBar will mean that our ternary operator will see that there are characters in our state.searchand render everything in the array...nothing!

A Little Something Extra

The counter shown in the examples above is more of a nice to have, but in some cases it might be useful to give the user some idea of how may items they have filtered down to. For example, typing the string "aut" into my search gives me 66 matches. Maybe I could be more specific before trying to scroll through all of that data. Oh yeah, "aut facere" gives me only 2 results! Great.

This is a simple little component which simply gets passed the length of the state.searchData array (or nothing, if there isn't anything, to save displaying 0 all of the time).

Here's the component itself:

And its implementation into App.js:

And that’s it! I hope I was able to share something interesting with you here, and I’d really appreciate any feedback on either the content or the writing. I’d like to do this more often and making it worthwhile would be a massive bonus.

You can find the sourcecode for this project on Github, and I will really appreciate a visit over on my website!

Create A Responsive Masonry Layout With Horizontal Flow

Martin Wheeler — Thu, 17 Sep 2020 13:41:41 +0000

Introduction

I love online photo galleries. You can get lost in photography for hours, particularly when the photographer really has something special to show off. It’s with that in mind that, as a developer and designer, you feel that justice has to be done to those images.

And this was my take on the infamous photo gallery project. I’m extremely happy with how it turned out and, although it may not seem much of an endeavour on the surface, it introduced me to a little something known as Masonry layout - and why there are a number of plugins and libraries developed to tackle just this. However, by the time I had decided what I wanted to achieve, I didn’t want to opt for a package to do this for me. I wanted to tackle this myself!

What is Masonry?

Masonry in web terms is the layout of unevenly sized tile, or brick, like elements in a way that there are only even gaps between them on both the x and y axis. It allows for a Pinterest-esque style look to your web page.

A quick search brings up multiple tutorials and suggestions from developers aiming to help you achieve this layout, in particular with a CSS only approach. I too really wanted to achieve this effect with only CSS, however there was always one downside to the solutions I found - the content flowed vertically. Given that this was a photographers website where content would be updated over time, it made sense to me that the images should flow from left to right, showing the newest uploads at the top of the page.

As it turned out, I wasn’t able to get what I was looking for using CSS alone without having either fixed height rows or vertical flow, both using flex or grid.

Tools For The Job

As is common lately I chose React as my working platform. This was simply because I knew I would be using a lot of components when building the rest of this portfolio site and I like how React, utilising useState and useEffect, makes handling API requests easy. For the CMS I chose Cosmic (formerly CosmicJS), a headless CMS with a very easy to use REST/GraphQL API and user-friendly dashboard for the client. It also provides a seemingly limitless free-tier and Imgix compression abilities. Win win!

So, without further ado, let’s move on from the why and what, to the how. I’m not planning on going into depth on how the entire site was put together - it’s a fairly simple React site using react-router-dom. I should also say that this isn’t a tutorial on React, styled-components, or any of the other tools I’ve used. We’ll jump right in at the gallery part.

Getting It Done

I used the following file structure for the gallery part of the project:

Let’s start by taking a look at GalleryPage.js. This is essentially the wrapper which all of the good stuff sits inside. From there, we can dig deeper.

As always we make our start with our imports. As I mentioned at the beginning, the gallery makes use of the useState and useEffect hooks provided natively by React, so we bring those in along with React itself. We then import styled-components which, for anyone who is unfamiliar with it, is a fantastic library for utilising JS-in-CSS. Bear in mind, you won’t need styled-components to make this work - you can simply import normal CSS files or S/CSS modules into your project.

I generally like to structure my imports as above, with native or npm provided imports at the top, logic/hooks/etc imports just after that, and lastly any components. It’s not gospel of course, it’s just the way I like to keep myself organised.

I’ll come back to the rest of the imports soon. For now, let’s take a look at the rest of GalleryPage.

There’s quite a lot going on there, so let’s break it down. First, we declare the component name which, in this instance, is GalleryPage. We then declare a number of variables which will be used to hold our site’s state.

isLoading and setIsLoading will, unsurprisingly, manage our loading sequence whilst we wait for fetch to retrieve our data, and imageData and setImageData will look after our data once it is retrieved. We’ll come back to the others shortly.

Using JavaScript’s fetch API we then make a request to the CosmicJS endpoint, for which you will need to get yourself an API key, and we receive back a JSON object. We can access the array we need under the object’s media key, so make sure that this is what you set as your state. Once we’ve set our state to our array using setImageData(data.media) we will now be able to use it to generate our images.

In the return statement for our component we need the following code:

The GalleryWrapper and GalleryWrapper elements have been created using styled-components, for now just think of them as any other React component. Inside here we map through our array and, ultimately, create our images. Now, the astute of you may have noticed something off in the code snippet above. We originally stored our array in the useState variable imageData, so why now are we trying to access something from sortedImageData?

This is where the important pieces of the puzzle come into play. Earlier we imported two additional modules - useWindowSize, which is a custom hook, and sortEveryNth, which is a JS function.

We’ll start by taking a look at the useWindowSize hook which is a custom hook with one important job to do - to listen out for any changes in our browser size and store that result in a state variable.

The hook makes use of both the native useLayoutEffect and useState hooks, and essentially adds an event listener to the window which fires each time a resize event occurs. This is the stored, and returned, as the constant size. To have a look into useLayoutEffect I recommend the docs.

Now we’ll take a look at the sortEveryNth function and see how this all fits together.

This function takes in two parameters, an array (the one that we want sorted) and a single number. This single number will reflect two things - the amount of columns we want to have in our gallery layout and, subsequently, the iteration count for the sorting algorithm.

The width we are using within this useEffect hook is the value that is being returned from the useWindowSize we just created, and from this value it is calculating whether to change state at some arbitrary break points - in this case 1366px, 1024px, and 800px.

Let’s say for example our browser width increases to, or is initially set at, 1400px. This fits into the first condition of the if statement, being greater than 1366px. setSortedImageData now calls the sortEveryNth function and passes in the imageData array to the first parameter, and the value of 4 as the second. The function now begins its work sorting the objects in the array by their index and returning a new array.

As this image hopefully explains well, the function skips through each item by n, which is in this case 4, and pushes the object into the new array. Once this is complete, the new array, imaginatively named newArr, is returned back to setSortedImageData and consequently stored into sortedImageData. And, after all of that, this is where we are mapping our data from, creating our GalleryImage components and appending them onto GalleryWrapper. The useEffect hook has both width and imageData in its dependency array, and these are responsible for ensuring everything is re-rendered once any changes occur to the browser size.

That’s essentially all of the heavy lifting out of the way. The last part to be put in place, to make sure everything works, is the CSS. I found that the use of column-count gave both the best and most predictable results.

It’s important to use media queries at the same breakpoints as you set in the useEffect hook as these will work in unison to both lay out the page and calculate the sorting correctly. As you can see I actually started this desktop first - not intentionally, it was just how it happened. And, as I mentioned before, any CSS will work here so don’t get hung up on how this looks outside of the CSS.

And that’s it! I hope I was able to share something interesting with you here, and I’d really appreciate any feedback on either the content or the writing. This is my first ever post, and I’d like to do this more often and making it worthwhile would be a massive bonus.

You can check out anything related to me or this project on my website