Template Literals

Tell us what’s happening:
I just want to know why you would do this? Why have a function called makeList that takes an array as a parameter then inside that function have a constant variable named resultDisplayArray then outside of the function have
const resultDisplayArray = makeList(result.failure);

This is confusing as hell…

Your code so far

const result = {
  success: ["max-length", "no-amd", "prefer-arrow-functions"],
  failure: ["no-var", "var-on-top", "linebreak"],
  skipped: ["id-blacklist", "no-dup-keys"]
function makeList(arr) {
  "use strict";

  // change code below this line
  const resultDisplayArray = [ `<li class="text-warning">no-var</li>`,
    `<li class="text-warning">var-on-top</li>`, 
    `<li class="text-warning">linebreak</li>` ];
  // change code above this line

  return resultDisplayArray;
 * makeList(result.failure) should return:
 * [ `<li class="text-warning">no-var</li>`,
 *   `<li class="text-warning">var-on-top</li>`, 
 *   `<li class="text-warning">linebreak</li>` ]
const resultDisplayArray = makeList(result.failure);

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36.

Link to the challenge:

In fact, a lot of the ES6 section of JS has been confusing to me and just hard to follow sometimes…

It’s about readability.

resultDisplayArray will always yield the same array inside the function and outside of it. Therefore, there is no need to name them differently because they have different scopes already.

It’s natural to feel confused going through ES6 section for the first time. Supplement your learnings with other resources and you will feel more comfortable and see why you would write codes in certain ways.

1 Like

I think you’re right, the code you’ve posted is duplicating logic and could be simplified a lot and still achieve the same thing. But I also think the code you posted isn’t complete yet (I haven’t done this particular problem so I’m not certain).

Just from looking at the code it looks like you’re supposed to change resultDisplayArray to be the result of something (probably arr.map()) so that makeList takes a list of strings and wraps them in html tags. In that case makeList is abstracting away that implementation so it would be worthwhile code to write.

1 Like

It’s verbose to show you the steps. Some input -> goes into a function -> that takes an array -> which you do an operation on (where you actually use the template literals) -> that returns the modified array -> you call the function with the input

It could just be

function example(arr) {
  return arr // modify this line

But it’s been kept in line with all the other JS challenges, which as a rule look like

var someInput = // blah

function example (input) {
  var someVar;
  // Your code here
  return someVar;

example(input) // this should be blah

As for putting it inside a function, that would be what you would generally do in practise. But yes, the way it’s laid out could be better.

1 Like

@shimphillip thanks for the response I found another course by Dylan Israel on scrimba that looks good. Also I just discovered scrimba for the first time. I usually try to find another tutorial when I don’t fully understand. I just feel like it’s all so out of context sometimes and that’s what feels so confusing. Maybe it’s not at all and I’m just in the process of learning.

@jay_aye_see_kay the code did work. after a while I realized the answer was right in the comments and I just copied that but because I didn’t get it and copied those comments I’m making sure I understand completely.

@DanCouper I think seeing the “It could just be:” helped the most for this. I have noticed that a certain format is used. Would you say that in most cases for the sake of the examples that it’s not necessarily what would be considered ‘clean code?’

Correct: it’s a lot more code than is needed, and as you’re discovering that can sometimes be more confusing than helpful. General rule of thumb is write as little code as possible whilst still being clear. Judging where that line is a whole other thing: it depends quite a lot on context [and experience]. Fewer operations often (not all the time) means less opportunity for bugs, and clearer code.

1 Like