So if you don’t know how to implement reduce, map and filter or if you just wan’t to take a look at how I did it. Head over to Filter and Map without Reduce, Filter and Map, read it, understand it, come back here 😊.

Reduce, Filter and Map without Reduce Filter and Map

So in the previous post I got a question on how to chain the self implemented versions of reduce, filter and map 🤔. I thought it was a good question and my way of combining the functions would be to compose them instead of chaining them.

☝ Also the way I’ve implemented them, as basic functions, there’s no this keyword so chaining as the JavaScript built in versions wouldn’t really be an option. I could rewrite all of it as a module pattern but prefer the basic functions. Another way is to override the built in Array methods but that’s a BIG no no!

So to compose these functions we need to make sure they all accept arrays as arguments and also returns arrays, so that the result from on function can be the input to the next one.

We also want to be able to “prep” our composable functions. For example if I want to filter out odd number from an array and then double the remaining numbers I would like it to look something like this when calling.

const double = x => x * 2
const even = x => x % 2 === 0;

const removeEvenAndDouble = compose(map(double), filter(even))
removeEvenAndDouble([1,2,3,4,5])

These composed functions create a flow where I would expect the returned value to be an array of [4,8]. So when I say “prep” functions I mean that I’ve already told map to use the double callback and filter to use the even callback. So when I call removeEvenAndDouble with the [1,2,3,4,5] array the array should be passed to the filter function, which runs the even function on each item, then returns the filtered array to the map function which runs the double function on each item.

So the array needs to be passed as the last argument to map and filter (the same goes for reduce). The arguments must also be passed one by one, so as long as the function doesn’t have all the arguments it need it will just sit there and relax. In other words we need curried functions.

I was also asked how to debug when combining / chaining / composing the self implemented functions. You could just use the browser dev tools and set breakpoints like any other program. But if you want a more “console.log fashion” we can use a “trace” function, it takes a label, returns a function that takes a value (it’s curried 😉), it prints the label and the value and returns the value. It looks like this.

const trace = label => value => {
  console.log(label, value)
  return value
}

Really simple! The trace function above is already a curried function as it takes one argument at the time and the “data” as it’s last argument. We could take all arguments at once and then write another function to curry the trace function. That way we have both a regular and a curried version of the trace.

A Function to Curry Functions

This function might give you a headache 🤯, it’s very compressed. Read it twice.

const curry = func => 
  (...args) => 
    (args.length < func.length) 
    ? (...moreArgs) => curry(func)(...args, ...moreArgs) 
    : func(...args);

Basically it takes a function, checks how many arguments that function needs to run. Compare the needed number of arguments to the arguments given. If it’s enough it runs the function with the given arguments. If it’s not enough arguments it returns a anonymous function that takes more arguments and then recalls the curry function with the old arguments plus the new ones and keeps doing that until it has all the arguments.

Here’s an example with the trace function.

const trace = (label, value => {
  console.log(label, value)
  return value
}

const curriedTrace = curry(trace)

trace("hello", "world") // logs "hello world"
curriedTrace("hello")("world") // logs "hello world"

As you’ve already figured out we’ll use this function to make curried versions of our reduce, filter and map from the previous post. But first we need to switch the arguments order.

New versions of Reduce, Map and Filter with switched arguments

Reduce

This is the same reduce as in the previous post, but with the array argument last. This also affects the internal argument order in map and filter (as we call reduce inside those functions) which we’ll handle below.

const reduce = (cb, initialValue, array) => {
  let result = initialValue;
  array.forEach(item =>
    result = cb.call(undefined, result, item, array));
  return result;
};

Map and Filter

Same goes here, array is the last argument. We’re also calling our reduce function with the array argument last.

const map = (func, array) =>
  reduce((result, item) =>
    result.concat(func(item)), [], array);

const filter = (func, array) =>
  reduce((result, item) =>
    func(item) ? result.concat(item) : result, [], array);

Make the curry

Now it’s dead simple to create curried versions of Reduce, Map and Filter, or any other function for that matter.

const curriedMap = curry(map);
const curriedFilter = curry(filter);
const curriedReduce = curry(reduce);

Composing

So now we got tracing to log the value with a label. We got the new versions of our functions with the array argument last and a function to curry it all! But we still need a function to compose our curried functions with. And as we saw in the beginning of this little text it should take some functions as argument, return another function which takes the initial value as it’s argument, which is passed to the first (actually the last, it runs from the bottom up) function and the result from the first function should be the input to the next and so on until we reach out last (first 😉) function. Then we get the result of the chain/compose flow. So here’s a implementation of the compose function.

const compose = (...funcs) => 
  initValue => 
    reduce(
     (funcResult, func) => func(funcResult), 
     initValue, 
     funcs.reverse()
   );

It takes functions as it’s argument and turns it into a array of function with the rest “…” operator. This returns a function which takes a initial value. Then it calls our implementation of reduce with a callback function, the initial value and the functions array, reversed as it’s how compose should work, bottom up, right to left, backwards.

Dummy Functions

We need some dummy functions to create a working example of composing our curried functions. Here they are.

const double = x => x * 2;
const even = x => x % 2 === 0;
const sum = (sum, x) => sum + x;

Put it together

Only thing left now is to Create the chain of functions, it runs from the bottom up, as “compose” functions should. Call the chain of function with a initial array.

const chain = compose(
 trace('after curried reduce'), // logs 12
  curriedReduce(sum, 0),        // array gets summed
  trace('after curried map'),   // logs [4,8]
  curriedMap(double),           // array gets doubled
  trace('after curried filter'),// logs [2,4]
  curriedFilter(even)           // array gets filtered
 );

chain([1,2,3,4,5]);

That’s it. Thanks for reading. Hope you learned something. Bye! 👋

Currying and Composing your own versions of Reduce, Filter and Map was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

A lot of people, including me, version control their dotfiles.

Most configs and settings for editors, terminals and alike live in your home folder “~”. But you don’t want to version control your whole home dorectory. So it’s necessary to keep all the configs and setting in a separate directory and move or link the config files to your home directory programmatically.

How do people do that? Usually with some complicated shell scripts that they write themselves. There’s nothing wrong in that, BUT I “found” this little GNU command line program called Stow. It’s brilliant for managing your dotfiles even though that’s not its intended use.

Lets take an example from the text editor Vim. It uses a .vimrc file and a .vim directory which both live inside the home directory. My .vimrc file and .vim directory are version controlled in my dotfiles git repository. It can obviously be cloned to any place in the file system. For example, lets say I’ve cloned my dotfiles repository to my home directory. My dotfiles directory looks like this.

/
/vim
/vim/.vimrc
/vim/.vim

Using Stow, all I’ve to do is to cd into my dotfiles directory and “Stow” the dotfiles subdirectory for the program I want to link up in my home directory.

$ cd ~/dotfiles
$ stow vim

This creates a symbolic link in my home directory for each file and directory inside my dotfiles/vim directory. As we can see Stow’s default behavior is to create symbolic links one level up the directory tree from where the command was ran.

If I want to clone my dotfiles repository to another place on the file system I start off the same by cd path/to/dotfiles. Then I just pass in my home directory as the target -t argument like stow vim -t ~. Now Stow will create symbolic links inside my home directory to my dotfiles/vim/.vimrc and dotfiles/vim/.vim wherever the dotfiles directory is located.

Smooth! 😎

Directories inside directories

In the case of Vim it uses the .vim folder for lots of stuff. I have specific settings for each filetype in my .vim directory. So settings for Python files live inside dotfiles/vim/.vim/after/ftplugin/python.vim. When I “Stow” the dotfiles/vim directory with stow vim -t ~ it creates a symbolic link at ~/.vim to dotfiles/vim/.vim. But Vim also uses ~/.vim for other stuff, like the file explorer history and it’s a suitable place to keep plugins for example.

But I don’t want to Vim’s file explorer history or pluggins in my dotfiles to be placed inside my dotfiles/vim/.vim directory. So I need a way to create a new directory for the dotfiles/vim/.vim/after directory at the target (my home folder). Stow comes with a handy argument for this, --no-folding . So by typing stow --no-folding vim -t ~ Stow creates the .vim folder in my home directory and symlinks the .vim/after to dotfiles/vim/.vim/after . So now the Vim file explorer can do it’s thing inside ~/.vim and the fantastic Vim plugin manager vim-plug can place pluggins inside ~/.vim/plugged while still keeping those files outside of my dotfiles repository.

🤯 This last bit with subdirectories might come across as a bit complicated, see the Stow manual on tree-folding for more infoillurmation and be sure to just try it out.

As you’ve already ended up on this page you probably already know what GNU Readline is, but for those who don’t, here’s the one-sentence explanation:

GNU Readline is a software library that provides line-editing and history capabilities for interactive programs with a command-line interface, such as Bash.

Most users come in contact with GNU Readline through the “Bash prompt” or
programs like the MySQL shell. Most of the GNU Readline settings can be set in each programs respective configuration file. Like .bashrc. But the .inputrc is specifically for GNU Readline. So the settings there will be inherited by any program that implements GNU Readline. In other words, same settings almost everywhere 🤓.

Settings

set bell-style none

Turns off any annoying beeps bash makes, like the one when you hammer the
backspace while you’re at the start of the prompt.

No more “ding ding ding” 🙌!

set colored-stats on
set colored-completion-prefix on

The first option, colored-stats, makes your completions colored just like when you ls --color=auto. The second line puts some color on the current prefix used to search possible completions. For example if you type apt- and then hit tab, the apt--part will be highlighted when GNU Readline gives you completion suggestions like apt-get and apt-cache.

set completion-ignore-case on
set completion-map-case on

The first line is self explanatory, it turns off case sensitivity. The second
option, completion-map-case isn’t a great label. What it does is to treat
hyphens - like underscores _ and vice versa. This option only works when completion-ignore-case is turned on, like above.

set echo-control-characters off

When your timing is off or your brain stops working when jumping around the
command line you just throw combinations like Ctrl+C for no reason. And
GNU Readline is polite, so it just thinks “what the hell” and echo out your
combo 🤜🤜🤛👊🤛🤜. This settings tells GNU Readline that it doesn’t have to bother.

set menu-complete-display-prefix on

When hitting Tab to search possible completions, GNU Readline will show you the common prefix for the possible completions and present them in a list. For example, if I have a package.json file and a package-lock.json file running vi p + Tab will make GNU Readline list the two files and append
to your prompt up to vi package. This is because all (both) possible
completions share the prefix `package`.

$if Bash
 Tab: menu-complete
$endif

By default, Bash binds a function called complete to the Tab key. That
function show a list of possible completions and completes up to the lowest
common prefix. If you keep hammering on the Tab key, just repeats this action. With Tab bound to menu-complete. Bash will cycle through the options as you keep hammering the Tab key, much better! There’s also menu-complete-backwards, hmm?? 🤔😉

There’s more

If you’re using the GNU Readline (command line) a lot and want to tweak and bend it. Fire up a terminal emulator and man readline.

Hope you had a nice read and you learned something. Bye. 👋

Vim

So in Vim I use the default bindings for resizing buffers. But I’ve tweaked them a bit 😏. The only thing I’ve done is to rebind the keys in whatever mode, so just noremap, to increase and decrease by 5 instead of the default 1.

noremap <C-w>+ :resize +5<CR>
noremap <C-w>- :resize -5<CR>
noremap <C-w>< :vertical:resize -5<CR>
noremap <C-w>> :vertical:resize +5<CR>

More info in Vim help system at :h window-resize.

Tmux

In Tmux I bind the same keys used in Vim (now with Tmux prefix obviously, I use Ctrl+A like most others). Here I change the value by 10 instead of 5. Only reason for this is that it feels right. I think the system are in columns and rows or something, but that doesn’t really matter.

bind-key -r ‘+’ resize-pane -U 10
bind-key -r ‘-’ resize-pane -D 10
bind-key -r ‘<’ resize-pane -L 10
bind-key -r ‘>’ resize-pane -R 10

The -r flag passed into the binding makes it repeatable. So when you press your prefix, you have a certain time to hammer > for example to make the pane increase to the right. The time you got depends on your repeat-time option which defaults to 500 milliseconds.

Thanks for reading 🙌👋

Common Way of Resizing Windows/Panes in Vim and Tmux was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

A fat stack of callbacks are usually the way to use route middleware/controllers in good old Express tutorials around the web. It works fine but is usually a mess to unit test in my opinion 🙄. Especially when the middleware/controllers stack grows to include authentication, validation etc.

A note on Middleware, Controllers, Route handlers in Express

Express is unopinionated on how you structure flow control in routes. So words like controllers, middleware and route handlers might mean different things or for the most part kind of the same thing 😕, confusing I know. However, there are some great examples on how to setup your routes at Express GitHub repository.

☝️ The structure I use for unit testing in this tutorial can be applied to any middleware/controller/route handler in express. So don’t worry about that.

How routes usually are structured

The very very simple example show the “classic” way of setting up a route.

app.get('/endpoint', verifyToken, validateRequest, getThings);

In this structure verifyToken and validateRequest has to call next() at some point so that the request can move along the stack. This makes unit test on a specific middleware harder than it needs to be. So, many tutorials end up writing something more like a integration test for the whole route. With that kind of test you don’t have to figure out if a middleware calls next(). Of course it can be done with stuff like SinonJS but I think it makes things more complicated then they need to be. Especially when you add more routes and use the same middleware in multiple routes.

Middleware as Promises

A first step to get around this issue is to structuring my middleware/controllers around Promises. That way I can use async/await or .then().catch() on my controllers inside each route. In other words I control the calling of next() inside the route and not the controller.

Let’s look at an example. Here’s a over simplified example of the verifyToken controller.

exports.verifyToken = (req, res) => 
  new Promise(async (resolve, reject) => {
    const token = req.cookies.token;
    if (token) {
     try {
       const user = await tokenFramework.verify(token, secret);
       req.user = user;
       resolve({ message: 'You have a valid token' });
     } catch (error) {
       reject({ message: 'Not a valid token', error });
     }
  };

And another example of the getThings controller.

exports.getThings = (req, res) => 
  new Promise(async (resolve, reject) => {
    try {
      const things = await Thing.find({req.params.id});
      resolve({ things });
    } catch (error) {
      reject({ message: 'Could not retrive things', error })
    }
  };

As you might figure out the main thing here is to return a Promise which will resolve() or reject() based on some logic inside the middleware/controller.

Handle Promises in the Route

As each middleware returns a promise I can just call then() on it and really do whatever I want. This is especially useful as it’s much clearer when next() is called and what happens throughout the middleware stack.

And of course, it makes unit testing specific middleware a breeze! ✌️

app.get('/endpoint',
  (req, res, next){
    verifyToken(req, res)
      .then(() => next())
      .catch(err => res.json(err))
  },
  (req, res, next){
    validateRequest(req, res)
      .then(() => next())
      .catch(err => res.json(err))
  },
  (req, res, next){
    getThings(req, res)
      .then(response => res.json(response))
      .catch(err => res.json(err))
  };

If you don’t play nice with .then() you can use async/await together with try/catch like that 👇.

...
async (req, res, next) {
  try {
    const response = await validateRequest(req, res);
    next();
  } catch (error) {
    res.json(error)};
},
...

Quick summery: Since I return a Promise from every controller middleware I moved the logic of calling next() to the route, very simple. If the promise resolves, call next() and proceed to the next middleware/controller or send the response to the client.

Run your tests

Now you just import the middleware in your test and the only thing you have to fake is the req and res . Use something like node-mocks-http for that.

Below I use tape for testing. I really like tape for it’s simplicity and it supports asynchronous testing in a clear simple way.

const test = require('tape');
const httpMocks = require('node-mocks-http');
const verifyToken = require('path/to/verifyToken');

test('verifyToken resolves with a success message', (assert) => {
  const req = httpMocks.createRequest({ 
    cookies: { token: 'blablabla' }
  });
  const res = httpMocks.createResponse();

  return verifyToken(req, res).then((response) => {
    ...
    assert.equal(typeof response.message, 'string');
    ...
  });
});

test('getThings resolves to an array of objects', (assert) => {
  const req = httpMocks.createRequest({ 
    params: { id: '12345' }
  });
  const res = httpMocks.createResponse();

  return getThings(req, res).then((response) => {
    ...
    assert.equal(Array.isArray(response.things), 'true');
    ...
  });
});

Since each controller now is self contained and only require a request and response as their arguments I can mock those and just call the function. No need to import your whole Express app or anything like that. Though if your working against a database, you have to connect to it in some way.

I’ve put together an app on GitHub that use Express, MongoDB and JSON Web tokens and has controllers/middleware to handle users, things (events in this case) and tokens. I hope you find it useful.

That’s it. Thanks for reading! 👋😎

Unit testing in Express with Promise-based Middleware and Controllers was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Write your own Reduce, Filter and Map without using the built in reduce() filter() and map().

A good way to understand what’s going on inside the functional programming must-know-functions is to rewrite them. So as a personal refresher I thought I would share how I implemented reduce() filter() and map(). Without any of the ES6 stuff. And non of the ES7 stuff either 😏.

A Simple Map

Then .map() method on Array runs every item in an array through a given callback function and returns a new array with the same length as the one the method called on.

The simplest version of map() I could think of looks like this.

function map(array, cb) {
  const result = [];
  for (let i = 0; i < array.length; i += 1 {      
    result.push(cb(array[i]));
  }
  return result;
}

Very straight forward here.

1. map() takes an array array and a callback function cb as arguments.
2. Declares an empty result array for storing the mapped items.
3. Loops all the items in the array.
4. Run the callback on the current item cb(array[i]).
5. Push the return value of the callback function into result.push(...).
6. Return the result when the loop is done.

Run it

map([1, 2, 3, 4, 5], item => item + 1); // [2, 3, 4, 5, 6]

A Simple Filter

The .filter() method on Array also runs every item in a given array against a callback function. However, the callback function should always evaluate to a Boolean. So basically it has to return true or false. The items that pass the callback evaluation are returned in a new array.

The implementation of filter() is almost the same thing as map() .

function filter(array, cb) {
  const result = [];
  for (let i = 0; i < array.length; i += 1) {
    if (cb(array[i])) {
      result.push(array[i]);
    }
  }
  return result;
}

The difference here, in comparison to map() is that the callback function cb has to evaluate to true or false. So inside the for loop, we call our callback with the current array item cb(array[i]) inside the if statement. If it evaluates to true , .push that sucker into the results array. When done, return the result.

Call it.

filter([1, 2, 3, 4, 5], item => item >= 3); // [3, 4, 5]

And a Simple Reduce

The .reduce() method is the Array multi tool and can be used in lots of scenarios. However, the fundamental functionality of reduce() is quite straight forward. The function takes tree arguments. An array to iterate upon. A callback function cb to run every item in the array through and an initialValue which you can think of as the container and the starting point for your callback cb results. If you want a string back pass in an empty string '', if you want an array pass an empty array [] and so one. Your initialValue dosen’t have to empty though. The type of initialValue is mostly dependent on what result your callback returns.

Being the multi tool, you might think the implementation is very different from filter() and map(). But it’s not. Along with the array and cb arguments I also pass the initialValue.

function reduce(array, cb, initialValue) {
  let result = initialValue;
  for (let i = 0; i < array.length; i += 1) {
    result = cb.call(undefined, result, array[i], i, array);
  }
  return result;
}

You’ve probably figured it all out already. But I’ll run through it anyway.

1. reduce() takes an array array and a callback function cb. Just like our filter() and map(). It also takes an initialValue, as I wrote, you can think of this as the container you want to receive as the return value of your reduce() . The initialValue is tightly coupled with how your callback cb works.
2. Declare a result variable and point it to your initialValue , this is just a reference for readability.
3. Loops all the items in the array.
4. Inside the loop, assign the return value of your callback to the result . Call the callback and set this to undefined and pass the result the current array item array[i], the loop iterator i and the whole array The last to isn’t really needed in this example but I’ve found it good practice to pass all the values. Since we are reassigning result on every loop iteration it’s crucial that your callback returns the entire result and not just the current item. I’m using .call on the cb function since I want to set this to undefined inside the callback.
5. When done, retuuuurn result!

Here’s how to call it.

reduce([1, 2, 3, 4, 5], (result, item) => {
  result.push(item * 2);
  return result;
}, []); // [ 2, 4, 6, 8, 10 ]

And here’s the same call but where I’ve broken out the callback for some clarity.

const cb = (result, item) => {
  result.push(item * 2);
  return result;
};

reduce([1, 2, 3, 4, 5], cb, []); // [ 2, 4, 6, 8, 10 ]

Use Reduce to Create Map and Filter 😲

Since reduce() is so flexible, you can use it to create your own map() and filter(). The key is, as you might figured out already, to switch the for loop out and replace it with reduce. Go ahead and try building them yourself before checking them out below .

Map with Reduce

function map(array, func) {
  return reduce(array, function (result, item) {
    result.push(func(item));
    return result;
  }, []);
}

I’m sure you can figure out what changed yourself, it works the same as our first map(). But now using reduce() internally. The main difference is that I wrapped a reduce() call inside of a map() function. To state the obvious this is a new map() function. It replaces the one I wrote from scratch above.

Call it the same way as before.

map([1, 2, 3, 4, 5], item => item + 1) // [ 2, 3, 4, 5, 6 ]

Here’s a more modern version with arrow functions, implicit return and .concat().

const map = (array, func) =>
  reduce(array, (result, item) =>
    result.concat(func(item)), []);

Filter with Reduce

function filter(array, func) {
  return reduce(array, function (result, item) {
    if (func(item)) {
      result.push(item);
      return result;
    }
    return result;
  }, []);
}

This one you can figure out yourself, so I’ll leave you to it. It’s kind of the same changes as in the previous map() with reduce(). Also call this the same way as we called our first filter().

filter([1, 2, 3, 4, 5], item => item >= 3); // [ 3, 4, 5 ]

And a more modern version of this can look like.

const filter = (array, func) =>
  reduce(array, (result, item) =>
    func(item) ? result.concat(item) : result, []);

Also, a modern version of Reduce

The only things I did here was switching the declaration to a functional expression using a arrow function and replaced the for loop with the .forEach() method. Very basic. If you have a awesome version of reduce, put it in the responses.

const reduce = (array, cb, initialValue) => {
  let result = initialValue;
  array.forEach(item =>
    result = cb.call(undefined, result, item, array));
  return result;
};

—

Hope you learned something. I sure was a good refresher for myself.
Take care! 👋

Reduce, Filter and Map without Reduce Filter and Map was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

A straight forward and awesome way to visualize your grid areas in text.

As CSS Grid started to roll out I was eager to play with it and one thing i found really nice was the “visualization” in text when you write out your grid-template-areas . Here’s an example of how the CSS maps really nice with the actual grid through 3 media queries.

Overall grid rulset

First of I use some basic CSS rules which looks like this.

.grid {
  display: grid;
  grid-gap: 1.5vw;
  min-height: 100vh;
  padding: 1.5vw;
}

It doesn't do anything special, just turn on the grid. Add some spacing and make sure it’s atleast as high as the viewport.

Small Screen

Before any media queries, since we’re building mobile first, I add some more rules to the .grid selector.

.grid {
  ...previous rules...
  grid-template-columns: repeat(2, 1fr);
  grid-template-rows: 50vh 30vh repeat(7, minmax(20vh, 1fr));

The first rule grid-template-columns: repeat(2, 1fr); adds 5 columns of equal with. I’m using 1fr instead of % or any other value since it’s doing calculations for grid-gap and padding right out of the box.

Second rule tells the grid how many rows there’s going to be. This one is pretty straight forward.

Small Screen Template Areas

Here comes the nice part! See how the rules below 👇 matches the boxes (!) on the screenshot to the left 👈 ( above ☝ on small screens). ️

.grid {
  grid-template-areas:
    "hero   hero"
    "big1   big1"
    "med1   med1"
    "med2   med2"
    "small1 small2"
    "small3 small4"
    "small5 small6"
    "small7 small8"
    "small9 small10";
}

Medium Screen Template Areas

As the screen grows we add a media query with new rules for columns and rows as well as template areas.

@media screen and (min-width: 750px) {
  .grid {
    grid-template-columns: repeat(5, 1fr);
    grid-template-rows: repeat(5, 25vh);
    grid-template-areas:
      "hero   hero   hero   med1   med1"
      "hero   hero   hero   med2   med2"
      "big1   big1   big1   big1   big1"
      "small1 small2 small3 small4 small5"
      "small6 small7 small8 small9 small10";
  }
}

Really simple, bump up the columns to 5 of equal width and make 5 rows with a height of 25% of the viewport height. So now we get this bad boy.

Bigger Screen Template Areas

From 1400 pixels we get lots of space to bump up the grid to something special. Let’s add some rules for that.

@media screen and (min-width: 1400px) {
  .grid {
    grid-template-columns: repeat(6, 1fr);
    grid-template-rows: auto;
    grid-template-areas:
    "small1 hero   hero hero med1   med1"
    "small2 hero   hero hero med2   med2"
    "small3 small5 big1 big1 small7 small8"
    "small4 small6 big1 big1 small9 small10";
  }
}

Here the mapping of the rules in CSS and the grid on the screenshot 👆 really maps out nicely 😍.

The rest of the CSS and HTML

Below our previous grid rules and media queries we add some more CSS to be able to put each HTML element in their respective grid-template-areas section.

.grid .item:nth-child(1)  { grid-area: hero; }
.grid .item:nth-child(2)  { grid-area: big1; }
.grid .item:nth-child(3)  { grid-area: med1; }
.grid .item:nth-child(4)  { grid-area: med2; }
.grid .item:nth-child(5)  { grid-area: small1; }
.grid .item:nth-child(6)  { grid-area: small2; }
.grid .item:nth-child(7)  { grid-area: small3; }
.grid .item:nth-child(8)  { grid-area: small4; }
.grid .item:nth-child(9)  { grid-area: small5; }
.grid .item:nth-child(10) { grid-area: small6; }
.grid .item:nth-child(11) { grid-area: small7; }
.grid .item:nth-child(12) { grid-area: small8; }
.grid .item:nth-child(13) { grid-area: small9; }
.grid .item:nth-child(14) { grid-area: small10; }

And the HTML for that looks like this. Very basic 😎.

<div class="grid ">
  ...
  <div class="item">
    ...
  </div>
</div>

I’ve published all code for this at codepen.io which also include a flexbox fallback.

That’s all 👋.