React’s Five Fingers of Death. Master these five concepts, then master React.

A few years ago, my friend Sean started telling me how this brand new front-end library called React was going to take over the web. At first I dismissed it as just another framework fad. But then I started hearing about React more and more, to the point where I felt like ignoring it just wasn’t an option anymore.

Maybe you’re in the same position I was in: you’ve been hearing about React left and right, but actually sitting down and learning it feels like such a chore.

The good news is that you can boil everything you need to know about React down to five key concepts.

Now don’t get me wrong, this doesn’t mean I can turn you into a React master instantly. But at least you’ll understand all the major concepts, if you do decide to jump in.

The five key concepts are:

  1. Components
  2. JSX
  3. Props & State
  4. The Component API
  5. Component Types

Before we get started, note that I originally learned React through Wes Bos’s courses, and have included a few affiliate links to them. Whenever possible, I’ve also included links to free resources.

Oh, and my friend Sean? He’s since moved on to much more cutting-edge-ier things. After all, React is so 2015.

Concept #1: How React components work

The first thing you need to know about React is that it’s all about components. Your React codebase is basically just one large pile of big components that call smaller components.

But what’s a component, you ask? A perfect example of a component is the common <select> HTML element. Not only does it come with its own visual output (the grey box, text label, and downward arrow that make up the element itself) — it also handles its own opening and closing logic.

The classic <select>

Now imagine being able to build your own self-contained custom <select>, with its own style and behavior:

A fancier version of the good old <select>

Well, that’s exactly what React lets you do. A React component is a single object that not only outputs HTML like a traditional template would, but also includes all the code needed to control that output. For Web designing services check Vivid Designs

In practice, the most common way to write React components is as an ES6 class containing a render method that returns HTML. (There’s also a super-secret functional way, but you’ll have to wait until concept #4 to learn about it):

class MyComponent extends React.Component {
  render() {
    return <p>Hello World!<p>;
  }
}

Concept #2: How JSX works

As you can see, the component approach means that both HTML and JavaScript code live in the same file. React’s secret weapon to achieve this unholy alliance is the JSX language (where “X” stands for “XML”).

JSX might seem awkward at first, but you get used to it pretty fast.

Yes, I know. We’ve all been taught to maintain a strong separation between HTML and JavaScript. But it turns out that relaxing these rules a bit can actually do wonders for your front-end productivity.

For example, since you now have the full power of JavaScript at your disposal, here’s how you can display the current date by inserting a snippet of JavaScript in your HTML using {...}:

class MyComponent extends React.Component {
  render() {
    return <p>Today is: {new Date()}</p>;
  }
}

This also means that you’ll use plain JavaScript for if statements or loops, rather than some kind of template-specific syntax. JavaScript’s ternary operator comes in especially handy here:

class MyComponent extends React.Component {
  render() {
    return <p>Hello {this.props.someVar ?  'World' : 'Kitty'}</p>;
  }
}

And by the way, if you need to brush up on the newest points of JavaScript syntax, I recommend ES6 for Everyone by Wes Bos (if you like videos) or Practical ES6 by Nicolas Bevacqua (if you prefer reading).

Concept #3: How Props & State work

Maybe you’ve been wondering where the this.props.someVar variable above is coming from.

If you’ve ever written a line of HTML, you’re probably familiar with HTML attributes like the <a> tag’s href. In React, attributes are known as props(short for “properties”). Props are how components talk to each other.

class ParentComponent extends React.Component {
  render() {
    return <ChildComponent message="Hello World"/>;
  }
}
class ChildComponent extends React.Component {
  render() {
    return <p>And then I said, “{this.props.message}”</p>;
  }
}

Because of this, React’s data flow is unidirectional: data can only go from parent components to their children, not the other way around.

Sometimes though, a component needs to react to data that doesn’t come from a parent component (such as user input for example). And this is where the state comes in.

A good metaphor to understand the difference between props and state would be the Etch-A-Sketch. Unlike things like the body color and dial position of the Etch-A-Sketch tablet (props), the drawing itself (state) is not an inherent property of the Etch-A-Sketch. It’s just the temporary result of user input.

Note that a component’s state can also be passed on to its own children as a prop. You can think of this as a big river flowing downhill, with the router, data layer, and various components each adding their own little stream of data to form the main app state.

Inside a component, state is managed using the setState function, which is often called inside an event handler:

class MyComponent extends React.Component {
  handleClick = (e) => {
    this.setState({clicked: true});
  }
  render() {
    return <a href="#" onClick={this.handleClick}>Click me</a>;
  }
}

In practice, the vast majority of data in a React app will be a prop. It’s only when you need to accept user input that you’ll use state to handle the change.

Note that we’re using a fat arrow here to take care of binding the handleClickhandler. You can learn more about this technique here.

Concept #4: How the Component API works

We’ve already mentioned render and setState, which are both part of a small set of component API methods. Another useful one is the constructor, which you can use to initialize your state and bind methods.

Apart from these three functions, React also provides a set of callbacks triggered at various points during the component’s lifecycle (before loading, after loading, after unmounting, and so on). Unless you’re doing some advanced React voodoo, you’ll probably almost never need to worry about these.

If this section seems short, it’s because learning React is actually much more about mastering programming and architectural concepts rather than learning a set of boring API methods. This is what makes it so refreshing!

Concept #5: How Component Types work

We’ve seen how to use classes to define a component:

class MyComponent extends React.Component {
  render() {
    return <p>Hello World!<p>;
  }
}

And we’ve also talked about the component methods supported by these classes. Now forget all about them! More and more, people are writing React components as functional components.

A functional component is a function that takes a props object as argument, and returns a bunch of HTML. Almost like a traditional template, with the key difference that you can still use whatever JavaScript code you need inside that function:

const myComponent = props => {
  return <p>Hello {props.name}! Today is {new Date()}.</p>
}

The consequence of using the functional component syntax is that you lose access to the component methods we just talked about. But it turns out that in practice that’s perfectly fine, since the vast majority of your components probably won’t need them. Web development company in Hyderabad visit Vivid Designs 

By the way, one of these methods is setState, and this means functional components cannot have state. For that reason they’re often referred to as stateless functional components.

Since functional components require much less boilerplate code, it makes sense to use them whenever possible. For this reason, most React apps contain a healthy mix of both syntaxes.

Note that there’s also a third, legacy syntax using the createClass function. But anybody using it should be shamed and called names for daring to still be using coding patterns from 18 months ago:

var Greeting = React.createClass({ 
  
  render: function() {     
    return <h1>Hello, {this.props.name}</h1>;   
  }
});

Concept #6: How Component Roles work

OK, I lied. There are actually six things, not five. But what can I say, the movie isn’t called “Six Fingers Of Death.” Although now that I think about it, that sounds like it’d be a pretty cool movie, probably involving some kind of alien kung-fu master seeking revenge.

But back to the topic at hand. Now come the boring architectural concepts I was talking about. So if none of this makes sense feel free to come back once you’ve had a chance to play with React some more.

After using React for a while, people started seeing two distinct “flavors” of code appear in their components: one flavor was concerned with UI logic such as showing and hiding thing. And the other was all about data logic, such as loading data from your server.

This led to the distinction between container and presentationalcomponents (also sometimes known as “smart” and “dumb” components). Container components should handle your data, but — and this is the important part — not your UI. Presentational components are just the opposite.

Google image result for “smart component”. I have no clue what this is. Image credit

In other words, in the classic to-do list example, one component will load the data, and then pass that data on to a different component that will be in charge of outputting the actual HTML markup and handling local state changes.

This is very similar to the view/controller pattern you might be familiar with from your back-end developer days. (’member Rails? ’member Django?)

The container/presentational distinction was popularized in this blog post by Dan Abramov (the creator of Redux), and I recommend checking it out if you want to dig deeper.

Higher-Order Components

Before we wrap things up, we should talk a bit about a type of container components known as higher-order components (often shortened as HoCs).

A HoC is a component that you can wrap around another component to pass it special props, and it’s typically created using a higher-order component factory function. Note that people commonly refer to the function itself as a “HoC”, which might not be 100% correct technically, but isn’t a big deal in practice.

As an example, calling React Router’s withRouter factory function on <MyComponent>will wrap it in a new<withRouter(MyComponent)/> component that passes the Router prop to the afore-mentioned <MyComponent>.

You can think of a HoC function as a golf caddie that follows their golfer around and hands them the club they need it. By themselves, the caddie can’t actually do anything with the golf clubs. They’re just there to give the golfer access to more tools.

HoCs are a very powerful concept. For example, the Recompose library even lets you handle state changes through HoCs. In other words, you can now manage state without having to involve any ES6 class-based components.

With HoC composition becoming so common, it seems like React might be moving away from the ES6 class syntax and more towards a purely functional approach. Interesting times!

Recap

So let’s recap what we’ve just learned:

  • A React codebase is made up of components.
  • These components are written using JSX.
  • Data flows from parent to children, except when it comes to state, which originates inside a component.
  • Components possess a small set of lifecycle and utility methods.
  • Components can also be written as pure functions.
  • You should keep data logic and UI logic in separate components.
  • Higher-order components are a common pattern for giving a component access to new tools.

Believe it or not, we’ve just covered 90% of the knowledge used by a React developer on a daily basis. No matter how abstract or obscure the pattern, everything in React can always be boiled down to functions and props.

Once you truly understand this, React will stop being scary. You’ll be able to see patterns in the code, understand new codebases at a glance, and only then will you be able to proudly proclaim:

“Pfff! React is so 2015!”

Going Further

If I’ve managed to convince you that React isn’t so bad, you might want to take a stab at learning it properly. If so, I can’t recommend the React for Beginnersvideo course enough. It’s how I learned React myself, and it’s actually just been updated to cover all the cool new stuff like functional stateless components:

If you don’t want your hard-earned dollars to finance the nefarious React lobby (I heard Dan Abramov is onto his third yacht), you can also learn for free by checking out this huge list of React resources.

And if you need to put all this newly-acquired knowledge in practice by contributing to a cool React open-source project, check out Telescope Nova. It’s the easiest way to quickly create a full-stack React + GraphQL app, complete with user accounts, forms, and data loading out of the box. And did I mention we’re looking for contributors?

Finally, if you’ve enjoyed this article, please share it and recommend it (that little green heart just below). And please let me know on Twitter what you’d like me to write about next!

Source

2017 is the year that front-end developers should go back and master the basics

In our fast-paced ecosystem, we tend to spend our time trying out the latest inventions, then arguing about them on the internet.

I’m not saying we shouldn’t do that. But we should probably slow down a bit and take a look at the things that don’t change all that much. Not only will this improve the quality of our work and the value we deliver — it will actually help us learn these new tools faster.

This post is a mix of my experience and my wishes for the New Year. And I want to hear your suggestions in the comments just as much as I want to share my own. For Web designing services check Vivid Designs

Learn how to write readable code

Most of our work lies not in writing new code, but maintaining existing code. That means you end up reading code much more often then writing it, so you need to optimize your code for the next programmer, not for the interpreter.

I recommend reading these three amazing books — in this order, from shortest to longest:

  • The Art of Readable Code by Dustin Boswell
  • Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
  • Code Complete: A Practical Handbook of Software Construction by Steve McConnell
  • Learn JavaScript deeper

    When every week we have a new JavaScript framework that’s better than any older framework, it’s easy to spend most of your time learning frameworks rather than the language itself. If you’re using a framework but don’t understand how it works, stop and start learning the language until you understand how the tools you use work.

    • A great start is Kyle Simpson’s book series You Don’t Know JavaScript, which you can read online for free.
    • Eric Elliott has a huge list of JavaScript topics to learn in 2017.
    • Henrique Alves has a list of things you should know before using React(actually any framework).
    • JavaScript Developers: Watch Your Language by Mike Pennisi — understand TC-39 process for new ECMAScript features.

    Learn functional programming

    For years we wanted classes in JavaScript. Now we finally have them but don’t want to use them anymore. Functions are all we want! We even write HTML using functions (JSX).

    • Functional-Light JavaScript by Kyle Simpson.
    • Professor Frisby’s Mostly adequate guide to functional programming ebook and his free course.
    • Learn design basics

      As front-end developers, we’re closer to users than anybody else on the team — maybe even closer than designers. And if designers have to verify every pixel you put on screen, you’re doing something wrong.

      • Design for Hackers: a book and a free course by David Kadavy.
      • Design for Non-Designers talk by Tracy Osborn.
      • Design of Web Applications by Nathan Barry.
      • On Web Typography by Jason Santa Maria.
      • The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper.
      • A few articles on animation in UI: How to Use Animation to Improve UX, Transitional Interfaces.

      Learn how to work with humans

      Some of us come to programming because we prefer to interact with computers more than with humans. Unfortunately, that’s not how it works.

      We rarely work in isolation: we have to talk to other developers, designers, managers — and sometimes even users. That’s hard. But it’s important if you want to really understand what you’re doing and why, because that’s where the value in what we do lies.

      • Soft Skills: The software developer’s life manual by John Sonmez.
      • The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin.
      • Start with No: The Negotiating Tools that the Pros Don’t Want You to Knowby Jim Camp.

      Learn how to write for humans

      A big portion of communication with our colleagues and other people are textual: task descriptions and comments, code comments, Git commits, chat messages, emails, tweets, blog posts, etc.

      Imagine how much time people spend reading and understanding all that. If you can reduce this time by writing more clearly and concisely, the world will be a better place to work. Best web development company in Hyderabad visit Vivid Designs 

      • On Writing Well: The Classic Guide to Writing Nonfiction by William Zinsser.
      • The Elements of Style by William Strunk and E. B. White.
      • Orwell’s rules on writing.
      • In Russian: awesome Glavred course.

      Learn the old computer science wisdom

      Front-end development isn’t just animated dropdown menus any more. It’s more complicated than ever before. Part of that notorious “JavaScript fatigue” stems from the increased complexity of the tasks we have to solve.

      This, however, means that it’s time to learn from all wisdom that non-front-end developers have built up over the decades. And this is where I want to hear your recommendations the most.

      Here are a couple resources I personally would recommend on this:

      • Learn To Think Like A Computer Scientist course at Coursera.
      • The five programming books that meant most to me by DHH
      • Source