React. The key points.
Tags: react, javascript, webdev, beginners
Published: 2018-03-15 08:11:49

---
title: React. The key points.
published: true
description: Talking about the key points of React.
tags: react, javascript, webdev, beginners
---

![React logo](https://logos-download.com/wp-content/uploads/2016/09/React_logo_wordmark.png)

# TL;DR

In this post, I'm talking about what I think are the key points of React. These are facts that I would happy to know while learning about the (spoiler alert) library.

By the way, it's my first post on dev.to. Hope you'll like it!

---

# It's not a framework

React has cool features, huge and active community and even its own javascript syntax! These facts can trick you into thinking that React is a framework. But it's not. As I spoiled before it's just a library.

Usually, a framework can provide you with everything you need to build an application. Look at angular, for example, it has so many features. View rendering, HTTP interaction, animations, form validation, you can find all of these in angular. React does only one of these - view rendering, and it does it pretty damn well.

Anything that is not about rendering a view is not a Reacts responsibility. Even if you want to render some part of an application using other tools, React is okay with that.

Every tool in software development has its cost. A Framework gives you more features for a greater cost. But despite its great features, the cost of React is relatively small. And I think that's why it's so popular. You can use it to render just one page or even just some component of your app. You don't need to pause feature development to migrate your whole app to React. If you think that react can do the job better, give it a try and implement just one component with React. React does give you this flexibility.

# It embraces javascript

This is also a good part of React not being a framework. Yeah, there is an additional syntax in JSX but this is just a syntactic sugar, unlike in Typescript which introduces new features like static typing to Javascript. The JSX code

```html
<Title large color="darkgray">
  Hello, World!
</Title>
```

simply compiles into

```javascript
React.createElement(
  Title,
  {large: true, color: 'darkgray'},
  'Hello, World!'
)
```

That's all.

Furthermore, it's still possible to write code for React components using pure Javascript but it's just not practical. Developers at Facebook could have developed much more features into JSX, but these would be just bells and whistles. Instead of that, React tries to make a developer use javascript as is and encourages one to find out and use the best practices.

It's also good news for javascript beginners. A developer learning React also learns vanilla Javascript and more flexible than developer learning Angular + Typescript. I myself learned Angular at first and then switched to React so I know what I'm talking about.

# Logic is fully your responsibility

As I said before React doesn't care about anything that's not rendering views. Despite the fact that many React apps are built in conjunction with Redux, nobody forces developers to do so. It's just a convenient way to build data flows in an app.

Components just need to get data to show as props. Where do you find it? None of their business.

# It's declarative

At this point, you can think. 

> If React is so small and does so few, why everybody think that it's so great?

Yes, react is small yet powerful. But it gains its powers not from many features but from great (and at first glance pretty sophisticated) paradigms. One of them is **declarative programming**.

To keep it short, in the declarative paradigm you describe **what** program should do, not **how** to do it. The way a developer describes a components view in React is declarative. You **declare** how a component should look with every possible set of props. 

For example, let's consider a simple checkbox-like component built with pure Javascript and React. 

Pure javascript version would look something like this 

```html
<button onclick="check()">Check</button>

<p>the flag is <span id="not">not</span> checked</p>

<script type="text/javascript">
  var checked = false;
  var notEl = document.getElementById('not');

  function check() {
    checked = !checked;
    notEl.innerText = checked ? '' : 'not';
  }
</script>
```

Here you should directly **mutate** the DOM. What's the problem with that? None, if there's only one node to mutate. But when app getting larger usually there is more than one mutation and that is when things become tricky. DOM mutations are hard to maintain, debug and test. And React is trying to tackle it (by not allowing mutations at all).

Here's what it would look like in react.

```jsx
import React from 'react';
import ReactDOM from 'react-dom';

const KindaCheckbox = ({ onCheck, isChecked }) => (
  <button onClick={onCheck}>Check</button>

  <p>the flag is { isChecked ? '' : 'not' } checked</p>
)

// these 2 lines are not best practices don't write code like that
let isChecked = false;
const onCheck = () => { isChecked = !isChecked };

ReactDOM.render(
  <KindaCheckbox onCheck={onCheck} isChecked={isChecked} />, 
  document.getElementById('root')
)
```

This may seem a bit complicated but the core idea is that you describe how your view should look at any moment in time no matter if the flag is checked or not. In other words, you declare **what** to show not **how** to **mutate** over time. And now you can focus on working with data, not with DOM. 

And that's why developers are freaking love it. Programming is not about moving divs around a web page it's about working with data! And React lets you forget about maintaining DOM and just do your job.

---

# Wrapping up

In my opinion, these are the most important considerations that you need to take into account before (or while) getting your hands on React. I hope these will help you to tackle the steep learning curve of React and build great applications using it.

---

Frankly, I was going to write about 3-4 more key points but it looks like this post is getting big. I'm thinking about part 2. If you think this is a good idea drop me a line in comments or on Twitter.