Front End Libraries Projects, curiosity question

Front End Libraries Projects, curiosity question
0

#1

I am currently developing a markdown previewer and it to hard for me, and I was wondering what if I check the final project source code and try to understand it and then later try to figure out how to build one on my own. Leave comments to let me know what you think.


#2

Don’t do that. It’s cheating. Ask your questions here. It’s encouraged!

Answers in this forum should be helpful hints instead of massive code-dumps.

What’s got you stuck? Got a link to your project?

[EDIT]: Cheating is bad for two reasons:

  1. [Less relevant to FCC but still true]: Software development is an industry of intellectual property, and claiming work as yours when it isn’t a very bad habit with legal ramifications later.
  2. [Extremely relevant to FCC]: Looking at someone else’s solution robs you of the chance to overcome the challenge. By getting frustrated and learning how to implement the solution in code yourself, you gain both the knowledge of how to do it and the frustration tolerance necessary to become a good programmer. Learning requires difficulty, otherwise you’d already know it.

#3

thanks alot, I guess there is no easy way around this


#4

If it makes you feel any better, @Muedgar, I’m in the same boat with the same project. It seems like such a large task to tackle right now! But breaking it down into small, manageable goals certainly helps.

Are you struggling with getting your project set up? I’m in the processing of solving setup problems myself. I decided to build the project using npm tooling so I can become more familiar with that toolchain.

Maybe we can help each other? :slightly_smiling_face:


#5

Sorry, I was on a family trip out of the country with spotty connectivity. So, here’s some actionable steps to take:

  1. Post a live version of what you have so far.
    • tell us what you are stuck with
  2. If you have no idea where to start, start with what is easier/less challenging. I like to start by crafting the UI in HTML and CSS, naming all the divs and whatnot per the user stories.
    • even if the final project is in a framework like React, it will be largely reusable as a jumping-off point
    • this makes the program logic much easier to conceptualize, since you now can say “oh, I need to take the text in #editor, run it through marked.js, and put the result into #preview.” I may have misremembered the exact div ids, but hopefully that gives you the idea of the utility of beginning with the interface.

#6

hi, I am sorry but I don’t understand anything about toolchain


#7

Yes I am struggling with getting the project set up


#8

Here is the way I am going to tackle this project:

1.start
2.write and algorithm for both editor and previewer
3.write the app in vanilla javascript
4.migrate code from vanilla javascript to react,…
5.and then check the project to pass the test
6.stop


#9

I think you’re making unnecessary work for yourself with step 3. The whole point of React is that it does two things very well:

  1. Makes you think of your UI in terms of components, that for larger projects, can be re-used so your code remains DRY (don’t repeat yourself principle). For example, I created a component for a general “window”, and composed it to create EditorWindow and PreviewWindow components that behave a little differently.

  2. Uses declarative programming, so that you can say “this is how I want my UI to look” based on the value of the variables that are in state (this.state object’s properties).

These two things interact in a way that leads to a third point which is not really a separate thing, but worth discussing: React lets you design reactive UIs easily. The application logic is clearly divided into two areas:

  1. declaration of the UI
    • This is always found in the render method of the largest component, usually called App.
  2. reaction to user input
    • found in the event handlers that get triggered when the user interacts with components. Logic that is similar is found in event handlers in vanilla JS, but the difference is the location in the code (class methods of stateful class components).

As a developer, these separation of concerns can help greatly with design and maintenance. It’s this division of concerns that gets me to design the basic UI in HTML/CSS first (I’ll cut/paste it into the render methods of the relevant components). I’ve finally reached the point in my React experience where I can code components straight-away, but it took 5 projects to get there, and it’s still faster to tweak/fiddle with things without the React boilerplate in a temporary text file if I’m trying to do something unfamiliar to me. Hope this helps you see how to get to your goal. Feel free to reply back.


#10

I don’t know much about the toolchain, either. That’s why I’m making it a goal to learn it with this simple app.

Have you every used CodePen? The Reactjs folks have a basic Hello World! CodePen template that you can fork. That way, all of the technical bits regarding setup are taken care of for you.

If you want to make styling a bit easier as well (i.e., minimize the amount of CSS you have to write), you can add Bootstrap or another similar library to your fork of the CodePen template.


#11

Thank you for explaining, I was struggling because I have mastered the concepts of react but now I understand a little


#14

There is one more thing I am struggling on, which is passing a table,list and code elements in marked.js