Test failing for markdown previewer. But, it functions as specified

I hope you guys aren’t getting tired of me. I’ve had to post so much lately over this one little project.

Finally got it up and running on github pages thanks to lasjorg.

But, now it’s failing tests that it should be passing. I mean, it does what the test is asking for… just maybe not in a way that’s expected by the tests?

What do I do?

Are you updating on keyup events, as specified, or something else? Could you provide a link to your source code?

Whoops. I posted it so often recently and forgot to add it here. My apologies.

The problem is likely that I am not using “marked” for the markdown because the moment I looked it up I found out that it shouldn’t be used at all because of the “dangerouslySetInnerHTML” thing, which I know nothing about other than to avoid it.

So, I used the most popular one, react-markdown. Maybe FCC just hasn’t updated their test suite in awhile?

I have no idea how the react-markdown component is dealing with keyup.

Here’s what it says in their info:

Made with react-markdown

react-markdown is a markdown component for React.

:point_right: Changes are re-rendered as you type.

:point_left: Try writing some markdown on the left.


  • Follows CommonMark
  • Optionally follows GitHub Flavored Markdown
  • Renders actual React elements instead of using dangerouslySetInnerHTML
  • Lets you define your own components (to render MyHeading instead of h1)
  • Has a lot of plugins

I was thinking how strange it is that there is so little information about each React component on https://www.npmjs.com when I remembered something lasjorg said about looking in the node_modules folder. I found the react-markdown folder and looked all around for anything useful. Nothing.

This is getting weird. When I was learning about SwiftUI it was like this too… kind of mysterious and hard to just go look things up when you need to.

Anyone know anything about that? Maybe I just don’t know where to look yet.

Did I ask the question wrong or something? Maybe everyone’s busy too. I couldn’t even get back to check on this for about a week. But, no replies in all that time. Hmm

Ya, there is a chance that the tests do not work properly with the react-markdown component. I think using that component might perhaps violate the “spirit” of the challenge. I’m not saying you are cheating in any way. The rules don’t necessarily appear to prohibit it. But I think the intention was to have you create the markdown editor and previewer yourself instead of just adding one with react-markdown.

So if you want to pass all of the tests then you might need to ditch react-markdown and go with the marked library instead.

What’s the difference between using “markdown” and “react-markdown” though? They’re both React components that one just plugs in. Nobody is reinventing that wheel again.

I don’t get where you’re even coming from with that idea.

Sorry, I don’t mean to sound rude. I really don’t understand how there’s any difference other than, when you look up “markdown” everyone says not to use it because of the “dangerously…Html” thing.

At this point it looks like it would be quicker to just make another stripped down version using the obsolete methods described by FCC and put on codepen or something.

I think my mistake was thinking that these FCC projects could be used to build more fleshed out apps for a portfolio. I mean, maybe they could. But, only after creating some simple version to pass the tests? Okay. Well, now I know so if I do any more they’ll be a breeze.

Ya, sorry about that, I didn’t look closely enough at react-markdown and thought it was doing more than it is. I think you should be able to use it and pass all the tests.

That’s big of you. Thank you. It’s a bit alarming to hear the c word in this context. I’m glad you came to your senses. :slightly_smiling_face:

We still don’t have an explanation for why the tests are failing though. I hope someone who understands the test suite code can chime in.

Whoa, now the forum is glitching out. I put a quote in that last reply and it’s just gone. And, when I posted it posted it as an edit. Weird.

Like I said, I wasn’t accusing you of cheating. Please reread my post:

“I think using that component might perhaps violate the “spirit” of the challenge. I’m not saying you are cheating in any way.”

Yes, I used the word “cheating” but to explicitly say I wasn’t accusing you of cheating.

You really ought to have the sense to not even imply something like that or use that word on a forum like this unless you have some kind of proof and are making an accusation.

It’s ok. Don’t get bent. Just maybe don’t do that to people anymore.

OK, I won’t tell people that they aren’t cheating any more. Got it. I think I’m done here. Good luck.

It seems like sometimes people come and try to take over a thread and cause some silly argument, so that nobody can get a good answer to the question.

I’m still looking for an answer to my original question about why the test suite is failing, yet the app does everything required.

That’s weird. You were able to make a quote. The last two I tried failed. This post has a quote too. Let’s see if it works this time.

I don’t understand why the people here would gang up on me like this. All I said was it is a bit alarming to hear the c word in this context. It seems over the top and extreme to even imply it by saying it like, "I’m not saying this… but, "

And, then he proceeds to say something I did is out of the spirit of the test, which is like another weak way of implying the same thing.

It’s pretty obvious if you aren’t trying to defend ugly behavior like that.

But, I really don’t care and I humbly ask everyone to stop trying to sabotage this thread with misunderstandings. I would like to get to the bottom of why the FCC test suite is apparently not working, or why my code doesn’t pass when the app does what is required as far as I can tell.


I think it was just a misunderstanding. As said, there really isn’t much difference between using a plain lib or a component lib. Although, I’d prefer a component lib with React so I’d say your solution is if anything “better”.

I can sort of fix the issue.

  1. Switch to the old React render (or downgrade to React 17). It is also possible that using the flushSync hook might work (it has to be used by wrapping the setters).

  2. I believe the preview id has to be on the direct parent of the markdown. But the component library does not support passing ids (which is a bit sad). If you use the components prop you can pass the id and class from the parent container. It is pretty convoluted. Below is an example.

<Card.Body className="markup" id="preview">
  {preview && (
        gfm ? [remarkGfm, remarkBreaks] : [remarkBreaks]
      rehypePlugins={syntax ? [rehypeHighlight] : []}
        div({ id, className, children, ...props }) {
          <div id={id} className={className} {...props}>
  1. For the last test you can add the remark-breaks plug-in (used in the example above).

  2. The initial load test still fails. Not sure if it is just the fetch that is too slow or what, but if I replace the markdown file with just some inline markdown inside a template string it passes the test. Anyway, I didn’t yet find a solution to using the markdown file and still have it pass the test. I guess you might have two versions of the project (with the test and not a markdown file, and without the test and with the markdown file).

Edit remarks: I had written about the highlighter not working but I now see why the highlighter didn’t work for me, it has to be a code fence with the language specified.


This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.