Markdown Previewer ClassName="converter"

Tell us what’s happening:
Just curious if someone can tell me why this line is in here. The CSS has rules for font-size, text-align and width but no height ( :thinking:). Any tips on how you might search for this? There are a lot of classNames, methods and abstractions that are new to me in React. I’ve been using developer.mozilla.org and reactjs.org et al but I’m finding a lot of tutorials are too limited while other searches are over my head. Its a work in progress.

Your code so far
line 78 of CSS:

.converter {
  border: 4px solid red;// I wrote this to "see it".
  width: 100px;
 text-align: center;
  font-size: 35px;
  margin: auto;
}

And on line 66 of JS

</div>
        <div className='converter' />// <<<----here
        <div className={classes[1]}>
          <Toolbar
            icon={classes[2]}
            onClick={this.handlePreviewMaximize}
            text='Previewer'
          />

Challenge: Build a Markdown Previewer

Link to the challenge:

In React (in JSX) you can’t use the world “class” because you are in JavaScript land and “class” is a reserved word with its own meaning. For this reason, in JSX, you say “className”. (There is a similar problem with “for” and “htmlFor”.)

So,

<div className='converter' />

is the same as

<div class='converter' />

in regular HTML. That is a pretty standard HTML device.

I know about class vs className. My qustion is “why is there a <div className='converter' /> placed between the editor and previewer?”

Here is what I know:
-className is “converter”
-css rules for .converter (see above)
-links to bootstrap and mocha.min.css
-searching “Mocha” brings up html, JS and CSS libraries, no luck finding actual content (this was the essence of our last discussion-How to review “content” of libraries)

  • Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun .
    -the link in the codepen for moch also has “ajax” in it.
    -functions like a

    questions:
    -Is it only there as a shim/space? then why have a className at all?
    -Does the .converter class have significance in bootstrap or “mocha”?
    -Why do they have font-size rules for a div with no text?
    -Does this mean the div is there for possible future uses or does it have a roll in transpiling the input from editor to preview.
    -Does the className="converter" div somehow help with asynchronous updates between the editor and the previewer? Is this why it is located between the the two?

-Is it only there as a shim/space? then why have a className at all?

Perhaps. But I also see that if I comment out the CSS it doesn’t seem to change anything. If I remove that div, it doesn’t seem to change anything. The class name doesn’t seem to give a clue. Maybe it has some effect on the flow that manifests itself in some screen size - I can’t see it.

I’m going to suggest that we don’t assume that every piece of code we find on the internet is perfectly constructed - especially on codepen. This may have been an idea that got abandoned or someone that just didn’t understand something. True, it is the FCC app, but people make mistakes, people have ideas that get lost. I don’t know who wrote this, but they are human and not perfect. Sometimes even monkeys fall out of trees.

-Does the .converter class have significance in bootstrap or “mocha”?

Well, mocha is a testing framework so I have no idea what it would be doing with css. But clearly it does.

But we can simply check. Those are just imported files. If I check those imported files out:

I can put those in my address bar, see the contents of the files, and search for the word “converter” - I get bupkis.

-Why do they have font-size rules for a div with no text?

That was a question I had too. Again, maybe someone smarter than me can see a reason for this, but I sure can’t. Again, don’t assume that this was written by a perfectionist expert that proofread everything they wrote.

-Does this mean the div is there for possible future uses or does it have a roll in transpiling the input from editor to preview.

I doubt it has anything to do with transpiling. Perhaps it was meant for future use.

I wasn’t around for the genesis of FCC. But I do know what it is like to build something from the ground up. In the beginning there is often a “lets just get something up and we can worry about cleaning it up later” attitude. This is a little bit of code in an app that works just fine - I’m sure it just never popped up on anyone’s radar. I assume those example projects were just built and left alone. The idea was that no one is going to be digging through their code - just looking at the output.

Or maybe there is a good reason for it that I’m not seeing.

-Does the className="converter" div somehow help with asynchronous updates between the editor and the previewer? Is this why it is located between the the two?

I can’t see how. Again, I think it’s just a mistake.

Looking at the history of the pen, I see that that pen was created as a fork from another pen (that doesn’t have that class) nearly 4 years ago.

If you go to the Contributors room, you might be able to find out more, maybe whoever built it is still here. But if they are, they may have no memory of that line. (I regularly scratch my head over things that I wrote 6 months ago.) Or maybe just don’t worry about it. There are much more useful things that you could learn rather than bike-shedding over this.

1 Like

Thanks for entertaining all of those Ideas. I came to mostly the same conclusions. The fork part is interesting. probably left over from the original.
My shedding efficiency has suffered lately with questions like these.

Here is my bleeding edge alpha version. I originally thought it would take me 4 hours, but I studied it for 3wks until I could write it from scratch…well from my notes anyway. Went smoothly until I had an error that crashed the whole app. Then I researched ErrorBoundaries, and somehow managed to find _html: needed to be __html:
Also somehow found a way to spend 2 hours finding just the right font-style, color and background.

Cool.

I would remove ErrorBoundary for the final app.

And one thing I don’t like is that the in the preview, things are centered - that is not an innate feature of markdown so it is not a true “preview” of what people will see.

And as I may have alluded to before, you can simplify your class components but instead of:

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      markdown: placeholder
    };
    this.handleChange = this.handleChange.bind(this);
  }
  handleChange(event) {
    this.setState({
      markdown: event.target.value
    });
  }

doing:

class App extends React.Component {
  state = {
      markdown: placeholder
  }; 

  handleChange = event => {
    this.setState({
      markdown: event.target.value
    });
  }

You can set state directly as a class property and if you use an arrow function for your method, you don’t need to bind this. That is a more modern way to write these things. Of course, nowadays, most people aren’t using classes, but that’s the next step.

Still, it looks good, have fun on the next one.

Thanks. I took out the centering and replaced it with 10px of padding to avoid the rounded corners cutting of text.

I didn’t catch that, but good to know, actually.

Thanks I am going to skip the drum machine and do the calculator. Quick question…I used the placeholder text word-for-word in this version. I notice that the underlines for headline and the lines for the table aren’t being rendered. I was surprised it passed. If you know off-hand why that would be I’m curious, but no biggie. I will figure it out when I polish these up later.
Thanks again

No, I don’t know off-hand. Let’s not let the perfect be the enemy of the good. You’ve learned what you can from this - enjoy the next one.

AMEN! (yes that is a sentence)

1 Like