Create Strings using Template Literals -conflicting messages

JavaScript
1

Tell us what’s happening:
Am I going mad or…

On the left it says ‘template strings were used’ = X

On the right it says
‘running tests
Template strings were used
tests complete’ (in green).

I mean, I may have got the code wrong (I don’t think I have), but the conflicting messages isn’t overly clear.

Anyone know what’s going on… is this a bug?

Thanks

image
image3684×2234 702 KB

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">${arr[0]}</li>`,
  `<li class="text-warning">${arr[1]}</li>`,
  `<li class="text-warning">${arr[2]}</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 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36.

Link to the challenge:

3

I agree with Randell’s assessment of why it is failing.

As to your question of the “conflicting messages”, I agree that this is a little confusing. On the right side, it is telling you what tests failed. It looks a little confusing because there is nothing to indicate the negative aspect - it looks like an affirmative statement, that “Template strings were used” - this is just the name of the test that failed. Notice that when you pass the left there is nothing on that side.

I agree it is confusing and could be improved. Maybe later I’ll see if someone has raised the issue on the github.

4

Thanks, I always get caught in the trap of ‘how best to solve this particular problem’ rather than considering the best way to solve to cater for different inputs etc.

I’ve used a .map to solve it now and frustratingly it works.

I say frustratingly, because in this instance it’s actually correct both ways, but because of a bug you go away thinking you’ve got it wrong the first time around…

Hopefully it gets fixed.

Thanks again.

5

So creating 3 template literals IS actually incorrect? haha. I’m confused now.

They have done a great job with the new FCC updates, but some of the UI stuff could use a bit more work IMO.

Thanks for your reply.

7

But the problem is that you were catering to the one test case you were seeing and not addressing the problem. Yes, if there were always exactly 3 messages, then either will work fine. And maybe it would be. But then imagine that you boss comes back to you and asks that it handle more. Are you going to go back into your code and change it every place you need to and hope that you don’t miss a spot. Or what if he just makes the change without checking with you and the system crashes. Using map makes more sense. Yes, it might be nice if the description made it clear that you had to handle different sizes of message arrays, but I would just assume this. For example, in the object shown, not all of the arrays have 3 messages. Not every problem description (in the real world) is going to tell you every single detail that you need to account for - you need to make some logical assumptions. To me, assuming that you need to account for different amounts of messages is logical, unless you were told otherwise. And remember that the test suite has other tests that aren’t shown.

8

Right, but I think the issue raised is the more general issue that on the right side, it lists the tests that failed but it looks like an affirmation that the test passed causing confusion. Something needs to be added to the make it clear. Instead of :

// running tests
Template strings were used
// tests completed

Maybe something like:

// running tests - tests that failed:
Template strings were used
// tests completed

And maybe the test that failed could also be in red.

9

Yeah fair point about the fact that it’s only catering to the one test, I definitely see the value in using a solution that caters to more test cases (I did actually end up using .map).

The main problem I have with it is that, because the instructions aren’t clear about what you’re trying to achieve in the first place, coupled with the fact that the test case reporting doesn’t make it very clear about what is failing, you end up guessing at what the problem is and also guessing at whether your ‘technically’ correct answer is failing because it’s a bug.

I.E. Because my solution is technically correct due to the ‘loose’ instructions, I could do without the hours of pointless confusion over something that is actually nothing to do with the code being incorrect.

As for assuming you need to account for different amount of messages, to me, it’s logically the other way around, in that because it’s a learning platform, why would I need to account for different amounts of messages unless I’m told otherwise. Obviously this can be interpreted differently though and I complete understand that in a ‘real world situation’ this would be very different, but as it’s for learning purposes at, I think FCC sometimes overcomplicates it.

I don’t know why including a line like: "This challenge will also test your ability to write code that tests for variable inputs’, just to really drill it into the user they need to consider. As, at this point, my go to isn’t always “test every use case”. This challenge is a small example of what could probably be applied across the whole platform, but then again everyone’s opinion is a bit different…

10

thanks guys. i was struggling with this for almost an hour…was only able to solve it after reading this.

Also it would be nice to correct the example from this:

// string interpolation
const greeting = Hello, my name is person.name!Iam{person.age} years old.;

to this:

// string interpolation
const greeting = Hello, my name is $ {person.name}! I am ${person.age} years old.;

1 Like
11

Yes, I agree the way the message is conveyed is confusing. But that is a separate issue.

As for assuming you need to account for different amount of messages, to me, it’s logically the other way around,

I guess we approach problems differently. You always need to assume something. And we should always be using best practices. And hard coding those replies in is not the best practice. Also, since “skipped” has only two messages, that would have been a logical assumption.

Yes, it is a teaching platform, but this reflects the real world. If I were building an app and the messages he gave me were always in threes, I would still use map because it is more scalable and is cleaner and is less prone to error (DRYer).

Interestingly, when I put a console.log statement in the function and see what it is passed, actually all the arrays have exactly 3 elements, the same as the test listed. So, that is not why it’s failing. It must check the method, otherwise you could just hard code in the answer.

But I think you need to flip your mindset. I don’t think the “but you didn’t tell me exactly what to do” attitude is going to serve you well. Most employers explicitly state they want the opposite.

But I agree the way the failure is communicated is flawed. And the problem would be improved if it was made clear that different numbers of messages need to be accounted for - and tested for.

12

Honestly that’s not where I’m coming from with regard to my attitude/how I approach things. What I mean is, I always try and approach things in context, so if this was the real world, I would think about it quite differently, but because it’s a training challenge, my first thought is why would they assume, as a student, I know they want a scalable answer.

I think the best thing I can do in the future is try and treat FCC as though it is the real world!

1 Like
13

Right, but FCC is not meant to be comprehensive. Yes, it would be best if during the map section of the training they had given you 20 problems and beaten into your head that this is best practice, but that would take too much time.

Maybe also because I do a lot of algorithm challenges, I’m used to this. Whether for a challenge web site or an job interview, I also ask myself three questions:

  1. What is the exact input? What are the bounds of the input?
  2. What is the exact output expected?
  3. What are the time/complexity issues?

Now, you may get times when and interviewer will be a little vague (as they are here) about something, because they expect you to ask - it is a warning sign if you don’t because you aren’t truly thinking about the problem. Like the old ironic saying goes, “Hours of debugging can save you minutes of planning.” Think about the problem first. In and interview situation, you have to ask. In this situation, you have to make a few logical assumptions. We’ve used map and other prototype methods before so they are not new. map should be your default for something like this, where you are looping over and array to create a new array.

When I did this problem, I noticed that it didn’t specify exactly three elements - the fact that the example had three is not evidence of this. Even if it specified the exact number of elements, I still would have used map because (even ignoring scalability) it is better practice, cleaner, and less prone to error.

Interestingly, using a for loop also fails. There must be something in the test suite that checks that map is used. And I agree that should be in the description with a better error message. But I also think it was a logical assumption. Hardcoding things like that is almost always a mistake.

14

I am a returner student. I had learnt to make higher order functions and of course I had played with the built-in ones: map filter and reduce. But even though I was aware of them, I was not in the mindset to use them.

Template literal is a very straight forward topic and I my brain was not in clever mode.

I wish I had be hinted not to hardcode the array, maybe the list element should be a lot longer to make ridiculous the extra work.