Learning React

Learning React is hard.

On one hand the code looks like HTML.  But it’s not straight HTML, it’s got other code decorators injected into it. As a result the browswer can’t read the files as it can read straight (vanilla) javascript.

An intermediate compiler/transpiler is needed to convert JSX (the HTML looking javascript) into JS that the browser can render.  This is what Babel is used for.

The first few times I tried to teach myself React, I got really hung up on JSX. I had a hard time keeping straight what it was used for, and it’s appearance being so similar to HTML kept confusing me. In reality it’s not HTML with some javascript thrown in, it’s JavaScript with HTML tags thrown right in.

In normal JavaScript you would have to encapsulate any HTML you wanted to send to the Document/Browser Window in string tags, which starts to look pretty messy. JSX allows you to not only write straight HTML markup in your JavaScript, but also create your own HTML tags, called Components via the React library. Now that I understand it’s purpose, it makes a whole lot more sense. If it’s confusing to you, stick with it.

Basic Starting Code

To start working with React, simply include two javascript libraries, one for React itself and one for ReactDOM to render what we are creating onto the browser window (the DOM).

You’ll need to include either a 3rd javascript library, or work with your tooling scripts to allow Babel to transpile your React code (JSX) into vanilla JS.

You can use these files locally by downloading them from here: https://facebook.github.io/react/docs/installation.html

<!DOCTYPE html>
<html>
<head>
    <title>Learning React</title>
    <script src="./js/react.min.js"></script>
    <script src="./js/react-dom.min.js"></script>
    <script src="../../js/browser.min.js"></script>
</head>
<body>

    
</body>
</html>

Don’t Let the Tooling Derail you

It can take time to wrap your head around the tooling options that are available.  What is “tooling?” Tooling is the set up of your local system to automatically compile your code, compact your JSX into vanilla JS to be use by your local or remote file server, a “linter” that will automatically check your syntax as you go, and so forth.

When set up correctly the right tooling can make your job very easy, but until you understand the purpose and function of each piece of tooling, it feels like a lot of extra code just to write some javascript.   Since javascript is supposed to be the language of the web, setting up a local React dev environment with the right tooling feels like a big step back in time.

But … they tell me it will be worth it!

Basic React Building Blocks

“Hello World”

Hello World is the traditional first step in learning any new coding language or framework. What’s the simplest way to get text on the screen.  In react it is a two step process. The first step is to simply create a “target” for your text by creating a single div with a name in your index.html file.

 

<div id="app"></div>

 

Next you tell ReactDOM to display “Hello World” to that target. If you’re writing this as a single file, simply create a script tag and mark it up as text/babel like this:

 

This is why we included the 3rd Javascript file above, so that the text/babel script will be correctly transpiled into javascript.

Now we “render” some text to our target using code that appears similar to HTML…but it’s actually JSX. The library used to render the JSX is ReactDOM, our 2nd included library above. We haven’t actually written any React yet, this is just the set up so that our React code has a way to be rendered and a target to go to. The render method takes two paramenters. The first one is basic HTML, and the 2nd is the target, which we’ve already created before.

 

ReactDOM.render(

Hello World!

, document.getElementById('app'))

Now if you open this index file in a local browser, assuming you’ve got proper script paths to react, reactDOM and babel, you should see your Hello, World! text on the page.

(A nice html server is

httpster

, that you can install with npm).

Here is the full index.html file up to this point:

<!DOCTYPE html>
<html>
<head>
    <title>Learning React</title>
    <script src="./js/react.min.js"></script>
    <script src="./js/react-dom.min.js"></script>
    <script src="../../js/browser.min.js"></script>
</head>
<body>
</body> </html>

Node.js: Redirecting to new page after an XML Delete request

I couldn’t think of a clearer way to title this post, other than describing the action I was trying to accomplish.  It took me 4 days to sort this out from hints I received online (Free Code Camp Gitter Help channel), the MDN Javascript documentation and a host of Stack Overflow questions.

The project I am working on is the Free Code Camp Voting App project. it’s the first of the full-stack apps, I used MEEN (Mongo ,Express,  EJS (or your choice of binding script), Node).

I first attempted this app 18 months ago, and failed miserably. Normally failure is an opportunity for learning, but it was so painfully challenging at that point because I barely grasped each component of the stack and getting them to work together was incredibly confusing for me.   I even used Yoeman, which SHOULD make it easier…but in reality it just made it more confusing for me. I was not ready to use that framework since I had a very thin grasp of how all the parts connected to each other.

Prior to this my only experience with full-stack was using Rails.   Some familiarity (but far from expertise) with Rails gave me a perspective of what I could / should be doing in terms of modularizing my application code.   JavaScript, however, allows you to make those decisions on your own about how you would like to configure your folders, scripts, public assets, routes, etc.

I ended up with what i felt was a reasonable blend of decent modularization, but also chunks of code contained in one file so that I was able to keep the parts straight. Perhaps future projects I’ll feel more comfortable making things more modular.

So here is the basic folder structure I opted for in my applicatoin. I’m NOT suggesting you do it the same way…this is simply how I ended up doing it and it’s working OK for right now. I’m sure i’ll make modifications , or possibly go back to yoeman, clementine.js or maybe try Sails.js for my next app.

fccVote2
-app
--poll.js  (this was catch all JS for the app..>I ended up not using it at all)
-bower_components  (front end scripts stored locally)
--chart.js
--chroma.min.js
-config  (files for authorization & authentication using passport)
--auth.js
--passport.js
-models (models for mongoose/mongo collections)
--index.js  (ties the other two in)
--poll.js  (poll model)
--user.js  (user model)
-public
--assets
---favicon.ico
---styles.css
--js
---chartPoll.js (again I ended up not using this, instead used embedded script tags)
-routes  (self explanatory)
--index.js
--polls.js
--users.js
-views
--pages (ejs templates)
--partials  (ejs partials for nav bar, header, footer, etc)
.gitignore
package.json
server.js
todo.txt (used webstorm's "TODO:" syntax to track bugs and todo items)

I started the project by working from the Scotch.io tutorial, Node Authentication with Passport.   I had done that tutorial once in the past, and it went well, so I rushed through it more quickly than I should have this time to get something propped up real quickly that i could use.  But once i got it working, I ignored the user sessions until after I had the voting routes & controller code working well.  That served me well, because once the app was mostly functioning I could then concentrate on allowing actions only for authorized users depending on the route (posting a new poll should only be allowed for authorized users for example)

The next task I tackled was using mongoose for the first time in an app, that is, not a tutorial.  This was not as difficult as I imaged it would be and I think in time it will be easier in the long run.  I think one of the big advantages is transparency of making the connection and closing the database…all that is done for you with Mongoose.  I’m still not fully aware of what other steps it saves, since straight vanilla node.js driver mongo is not really all that challenging (minus callback hell).

At this point I needed to get some data into my database (using mLab, but could easily use local installation of mongod), and I didn’t want to fuss with the front end.  In all the mongo documentation, they provide a small database collection creation script that you run prior to running the commands.  

========================

This post is a draft I started a few months ago and can’t readily recall all the details I wanted to include. However there is some good reminders in here and hopefully they will help some others, so I am publishing it anyway