DEV Community: Andrej Naumovski

Async actions in Redux with RxJS and Redux Observable

Andrej Naumovski — Mon, 28 May 2018 12:21:42 +0000

Introduction

What is Redux?

Redux is an amazing library. For those of you who don't know what Redux is, it is a predictable state container for JavaScript apps. In English, it acts as a single source of truth for your application's state. The state, or Redux store, as it is called, can only be altered by dispatching actions, which are handled by reducers, who dictate how the state should be modified depending on the type of action dispatched. For those of you who aren't familiar with Redux, check out this link.

Now, Redux is most commonly used in combination with React, although it's not bound to it - it can be used together with any other view library.

Redux's issue

However, Redux has one, but very significant problem - it doesn't handle asynchronous operations very well by itself. On one side, that's bad, but on the other, Redux is just a library, there to provide state management for your application, just like React is only a view library. None of these constitute a complete framework, and you have to choose the tools you use for different things by yourself. Some view that as a bad thing since there's no one way of doing things, some, including me, view it as good, since you're not bound to any specific technology. And that's good, because everyone can choose the tech that they think fits the best to their needs.

Handling asynchronous actions

Now, there are a couple of libraries which provide Redux middleware for handling asynchronous operations. When I first started working with React and Redux, the project that I was assigned to used Redux-Thunk. Redux-Thunk allows you to write action creators which return functions instead of plain objects (by default all actions in Redux must be plain objects), which in turn allow you to delay dispatching of certain actions.

And as a beginner in React/Redux back then, thunks were pretty awesome. They were easy to write and understand, and didn't require any additional functions - you were basically just writing action creators, just in a different way.

However, once you start to get into the workflow with React and Redux, you realize that, although very easy to use, thunks aren't quite that good, because, 1. You can end up in callback hell, especially when making API requests, 2. You either stuff your callbacks or your reducer with business logic for handling the data (because, let's be honest, you're not going to get the perfectly formatted data EVERY time, especially if you use third-party APIs), and 3. They're not really testable (you'd have to use spy methods to check whether dispatch has been called with the right object). So, I started to research for other possible solutions that would be a better fit. That's when I ran into Redux-Saga.

Redux Saga was very close to what I was looking for. From its website, The mental model is that a saga is like a separate thread in your application that's solely responsible for side effects. What that basically means is that sagas run separately from your main application and listen for dispatched actions - once the action that that particular saga is listening for is dispatched it executes some code which produces side effects, like an API call. It also allows you to dispatch other actions from within the sagas, and is easily testable, since sagas return Effects which are plain objects. Sounds great, right?

Redux-Saga DOES come with a tradeoff, and a big one for most devs - it utilizes Javascript's generator functions, which have a pretty steep learning curve. Now, props (see what I did there, hehe) to the Redux Saga creators for using this powerful feature of JS, however, I do feel that generator functions feel pretty unnatural to use, at least for me, and even though I know how they work and how to use them, I just couldn't get around to actually using them. It's like that band or singer that you don't really have a problem listening to when they're played on the radio, but you would never even think about playing them on your own. Which is why my search for the async-handling Redux middleware continued.

One more thing Redux-Saga doesn't handle very nicely is cancellation of already dispatched async actions - such as an API call (something Redux Observable does very nicely due to its reactive nature).

The next step

A week or so ago, I was looking at an old Android project a friend and I had written for college and saw some RxJava code in there, and thought to myself: what if there's a Reactive middleware for Redux? So I did some research and, well, the gods heard my prayers: Cue Redux Observable.

So what is Redux Observable? It is another middleware for Redux that lets you handle asynchronous data flow in a functional, reactive and declarative way. What does this mean? It means that you write code that works with asynchronous data streams. In other words, you basically listen for new values on those streams (subscribe to the streams*) and react to those values accordingly.

For the most in-depth guides on reactive programming in general, check out this link, and this link. Both give a very good overview on what (Functional) Reactive Programming is and give you a very good mental model.

What problems does Redux Observable solve?

The most important question when looking at a new library/tool/framework is how it's going to help you in your work. In general, everything that Redux Observable does, Redux-Saga does as well. It moves your logic outside of your action creators, it does an excellent job at handling asynchronous operations, and is easily testable. However, IN MY OPINION, Redux Observable's entire workflow just feels more natural to work with, considering that both of these have a steep learning curve (both generators and reactive programming are a bit hard to grasp at first as they not only require learning but also adapting your mindset).

From the Redux Observable official guide: The pattern of handling side effects this way is similar to the "process manager" pattern, sometimes called a "saga", but the original definition of saga is not truly applicable. If you're familiar with redux-saga, redux-observable is very similar. But because it uses RxJS it is much more declarative and you utilize and expand your existing RxJS abilities.

Can we start coding now?

So, now that you know what functional reactive programming is, and if you're like me, you really like how natural it feels to work with data. Time to apply this concept to your React/Redux applications.

First of all, as any Redux middleware, you have to add it to your Redux application when creating the store.

First, to install it, run
npm install --save rxjs rxjs-compat redux-observable
or
yarn add rxjs rxjs-compat redux-observable
depending on the tool that you're using.

Now, the basis of Redux Observable are epics. Epics are similar to sagas in Redux-Saga, the difference being that instead of waiting for an action to dispatch and delegating the action to a worker, then pausing execution until another action of the same type comes using the yield keyword, epics run separately and listen to a stream of actions, and then reacting when a specific action is received on the stream. The main component is the ActionsObservable in Redux-Observable which extends the Observable from RxJS. This observable represents a stream of actions, and every time you dispatch an action from your application it is added onto the stream.

Okay, let's start by creating our Redux store and adding Redux Observable middleware to it (small reminder, to bootstrap a React project you can use the create-react-app CLI). After we're sure that we have all the dependencies installed (redux, react-redux, rxjs, rxjs-compat, redux-observable), we can start by modifying our index.js file to look like this

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';

import { createStore, applyMiddleware } from 'redux';
import { createEpicMiddleware } from 'redux-observable';
import { Provider } from 'react-redux';

const epicMiddleware = createEpicMiddleware(rootEpic);

const store = createStore(rootReducer, applyMiddleware(epicMiddleware));

const appWithProvider = (
    <Provider store={store}>
        <App />
    </Provider>
);

ReactDOM.render(appWithProvider, document.getElementById('root'));

As you might have noticed, we're missing the rootEpic and rootReducer. Don't worry about this, we'll add them later. For now, let's take a look at what's going on here:

First of all, we're importing the necessary functions to create our store and apply our middleware. After that, we're using the createEpicMiddleware from Redux Observable to create our middleware, and pass it the root epic (which we'll get to in a moment). Then we create our store using the createStore function and pass it our root reducer and apply the epic middleware to the store.

Okay, now that we have everything set up, let's first create our root reducer. Create a new folder called reducers, and in it, a new file called root.js. Add the following code to it:

const initialState = {
    whiskies: [], // for this example we'll make an app that fetches and lists whiskies
    isLoading: false,
    error: false
};

export default function rootReducer(state = initialState, action) {
    switch (action.type) {
        default:
            return state;
    }
}

Anyone familiar with Redux already knows what's going on here - we're creating a reducer function which takes state and action as parameters, and depending on the action type it returns a new state (since we don't have any actions defined yet, we just add the default block and return the unmodified state).

Now, go back to your index.js file and add the following import:

import rootReducer from './reducers/root';

As you can see, now we don't have the error about rootReducer not existing. Now let's create our root epic; first, create a new folder epics and in it create a file called index.js. In it, add the following code for now:

import { combineEpics } from 'redux-observable';

export const rootEpic = combineEpics();

Here we're just using the provided combineEpics function from Redux Observable to combine our (as of now, nonexistent) epics and assign that value to a constant which we export. We should probably fix our other error in the entry index.js file now by simply adding the following import:

import { rootEpic } from './epics';

Great! Now that we handled all the configuration, we can go and define the types of actions that we can dispatch and also action creators for those whiskies.

To get started, create a new folder called actions and an index.js file inside.
(Note: for large, production-grade projects you should group your actions, reducers and epics in a logical way instead of putting it all in one file, however, it makes no sense here since our app is very small)

Before we start writing code, let's think about what types of actions we can dispatch. Normally, we would need an action to notify Redux/Redux-Observable that it should start fetching the whiskies, let's call that action FETCH_WHISKIES. Since this is an async action, we don't know when exactly it will finish, so we will want to dispatch a FETCH_WHISKIES_SUCCESS action whenever the call completes successfully. In similar manner, since this is an API call and it can fail we would like to notify our user with a message, hence we would dispatch a FETCH_WHISKIES_FAILURE action and handle it by showing an error message.

Let's define these actions (and their action creators) in code:

export const FETCH_WHISKIES = 'FETCH_WHISKYS';
export const FETCH_WHISKIES_SUCCESS = 'FETCH_WHISKYS_SUCCESS';
export const FETCH_WHISKIES_FAILURE = 'FETCH_WHISKYS_FAILURE';

export const fetchWhiskies = () => ({
    type: FETCH_WHISKIES,
});

export const fetchWhiskiesSuccess = (whiskies) => ({
    type: FETCH_WHISKIES_SUCCESS,
    payload: whiskies
});

export const fetchWhiskiesFailure = (message) => ({
    type: FETCH_WHISKIES_FAILURE,
    payload: message
});

For anyone who is unclear about what I'm doing here, I'm simply defining constants for the action types and then using the lambda shorthand notation of ES6 I am creating arrow functions which return a plain object containing a type and (optional) payload property. The type is used to identify what kind of action has been dispatched and the payload is how you send data to the reducers (and the store) when dispatching actions (note: the second property doesn't have to be called payload, you can name it anything you want, I'm doing it this way simply because of consistency).

Now that we've created our actions and action creators, let's go and handle these actions in our reducer:
Update your reducers/index.js to the following.

import {
    FETCH_WHISKIES,
    FETCH_WHISKIES_FAILURE,
    FETCH_WHISKIES_SUCCESS
} from '../actions';

const initialState = {
    whiskies: [],
    isLoading: false,
    error: null
};

export default function rootReducer(state = initialState, action) {
    switch (action.type) {
        case FETCH_WHISKIES:
            return {
                ...state,
                // whenever we want to fetch the whiskies, set isLoading to true to show a spinner
                isLoading: true,
                error: null
            };
        case FETCH_WHISKIES_SUCCESS:
            return {
                whiskies: [...action.payload],
                // whenever the fetching finishes, we stop showing the spinner and then show the data
                isLoading: false,
                error: null
            };
        case FETCH_WHISKIES_FAILURE:
            return {
                whiskies: [],
                isLoading: false,
                // same as FETCH_WHISKIES_SUCCESS, but instead of data we will show an error message
                error: action.payload
            };
        default:
            return state;
    }
}

Now that we've done all that, we can FINALLY write some Redux-Observable code (sorry for taking so long!)

Go to your epics/index.js file and let's create our first epic. To start off, you're going to need to add some imports:

import { Observable } from 'rxjs';
import 'rxjs/add/operator/switchMap';
import 'rxjs/add/operator/map';
import 'rxjs/add/observable/of';
import 'rxjs/add/operator/catch';
import { ajax } from 'rxjs/observable/dom/ajax';

import {
    FETCH_WHISKIES,
    fetchWhiskiesFailure,
    fetchWhiskiesSuccess
} from "../actions";

What we did here is import the action creators that we will need to dispatch as well as the action type that we will need to watch for in the action stream, and some operators from RxJS as well as the Observable. Note that neither RxJS nor Redux Observable import the operators automatically, therefore you have to import them by yourself (another option is to import the entire 'rxjs' module in your entry index.js, however I would not recommend this as it will give you large bundle sizes). Okay, let's go through these operators that we've imported and what they do:

map - similar to Javascript's native Array.map(), map executes a function over each item in the stream and returns a new stream/Observable with the mapped items.
of - creates an Observable/stream out of a non-Observable value (it can be a primitive, an object, a function, anything).
ajax - is the provided RxJS module for doing AJAX requests; we will use this to call the API.
catch - is used for catching any errors that may have occured
switchMap - is the most complicated of these. What it does is, it takes a function which returns an Observable, and every time this inner Observable emits a value, it merges that value to the outer Observable (the one upon which switchMap is called). Here's the catch tho, every time a new inner Observable is created, the outer Observable subscribes to it (i.e listens for values and merges them to itself), and cancels all other subscriptions to the previously emitted Observables. This is useful for situations where we don't care whether the previous results have succeeded or have been cancelled. For example, when we dispatch multiple actions for fetching the whiskies we only want the latest result, switchMap does exactly that, it will subscribe to the latest result and merge it to the outer Observable and discard the previous requests if they still haven't completed. When creating POST requests you usually care about whether the previous request has completed or not, and that's when mergeMap is used. mergeMap does the same except it doesn't unsubscribe from the previous Observables.

With that in mind, let's see how the Epic for fetching the whiskies will look like:

const url = 'https://evening-citadel-85778.herokuapp.com/whiskey/'; // The API for the whiskies
/*
    The API returns the data in the following format:
    {
        "count": number,
        "next": "url to next page",
        "previous": "url to previous page",
        "results: array of whiskies
    }
    since we are only interested in the results array we will have to use map on our observable
 */

function fetchWhiskiesEpic(action$) { // action$ is a stream of actions
    // action$.ofType is the outer Observable
    return action$
        .ofType(FETCH_WHISKIES) // ofType(FETCH_WHISKIES) is just a simpler version of .filter(x => x.type === FETCH_WHISKIES)
        .switchMap(() => {
            // ajax calls from Observable return observables. This is how we generate the inner Observable
            return ajax
                .getJSON(url) // getJSON simply sends a GET request with Content-Type application/json
                .map(data => data.results) // get the data and extract only the results
                .map(whiskies => whiskies.map(whisky => ({
                    id: whisky.id,
                    title: whisky.title,
                    imageUrl: whisky.img_url
                })))// we need to iterate over the whiskies and get only the properties we need
                // filter out whiskies without image URLs (for convenience only)
                .map(whiskies => whiskies.filter(whisky => !!whisky.imageUrl))
            // at the end our inner Observable has a stream of an array of whisky objects which will be merged into the outer Observable
        })
        .map(whiskies => fetchWhiskiesSuccess(whiskies)) // map the resulting array to an action of type FETCH_WHISKIES_SUCCESS
        // every action that is contained in the stream returned from the epic is dispatched to Redux, this is why we map the actions to streams.
        // if an error occurs, create an Observable of the action to be dispatched on error. Unlike other operators, catch does not explicitly return an Observable.
        .catch(error => Observable.of(fetchWhiskiesFailure(error.message)))
}

After this, there's one more thing remaining, and that is to add our epic to the combineEpics function call, like this:

export const rootEpic = combineEpics(fetchWhiskiesEpic);

Okay, there's a lot going on here, I'll give you that. But let's break it apart piece by piece.

ajax.getJSON(url) returns an Observable with the data from the request as a value in the stream.
.map(data => data.results) takes all values (in this case only 1) from the Observable, gets the results property from the response and returns a new Observable with the new value (i.e only the results array).

.map(whiskies => whiskies.map(whisky => ({
                    id: whisky.id,
                    title: whisky.title,
                    imageUrl: whisky.img_url
                })))

takes the value from the previous observable (the results array), calls Array.map() on it, and maps each element of the array (each whisky) to create a new array of objects which only hold the id, title and imageUrl of each whisky, since we don't need anything else.

.map(whiskies => whiskies.filter(whisky => !!whisky.imageUrl)) takes the array in the Observable and returns a new Observable with the filtered array.

The switchMap that wraps this code takes this Observable and merges the inner Observable's stream to the stream of the Observable that calls switchMap. If another request for the whiskies fetch came through, this operation would be repeated again and the previous result discarded, thanks to switchMap.

.map(whiskies => fetchWhiskiesSuccess(whiskies)) simply takes this new value we added to the stream and maps it to an action of type FETCH_WHISKIES_SUCCESS which will be dispatched after the Observable is returned from the Epic.

.catch(error => Observable.of(fetchWhiskiesFailure(error.message))) catches any errors that might have happened and simply returns an Observable. This Observable is then propagated through switchMap which again merges it to the outer Observable and we get an action of type FETCH_WHISKIES_FAILURE in the stream.

Take your time with this, it is a complicated process which, if you haven't ever touched Reactive programming and RxJS, can look and sound very scary (read those links I provided above!).

After this, all we need to do is render a UI, which will have a button that dispatches the action and a table to show the data. Let's do that; start off by creating a new folder called components and a new component called Whisky.jsx.

import React from 'react';

const Whisky = ({ whisky }) => (
    <div>
        <img style={{ width: '300px', height: '300px' }} src={whisky.imageUrl} />
        <h3>{whisky.title}</h3>
    </div>
);

export default Whisky;

This component simply renders a single whisky item, its image and title. (Please, for the love of God, never use inline styles. I'm doing them here because it's a simple example).

Now we want to render a grid of whisky elements. Let's create a new component called WhiskyGrid.jsx.

import React from 'react';

import Whisky from './Whisky';

const WhiskyGrid = ({ whiskies }) => (
    <div style={{ display: 'grid', gridTemplateColumns: '1fr 1fr 1fr' }}>
        {whiskies.map(whisky => (<Whisky key={whisky.id} whisky={whisky} />))}
    </div>
);

export default WhiskyGrid;

What WhiskyGrid does is it leverages CSS-Grid and creates a grid of 3 elements per row, simply takes the whiskies array which we will pass in as props and maps each whisky to a Whisky component.

Now let's take a look at our App.js:

import React, { Component } from 'react';
import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';
import './App.css';

import { fetchWhiskies } from './actions';

import WhiskyGrid from './components/WhiskyGrid';

class App extends Component {
  render() {
    const {
      fetchWhiskies,
      isLoading,
      error,
      whiskies
    } = this.props;

    return (
      <div className="App">
        <button onClick={fetchWhiskies}>Fetch whiskies</button>
        {isLoading && <h1>Fetching data</h1>}
        {!isLoading && !error && <WhiskyGrid whiskies={whiskies} />}
        {error && <h1>{error}</h1>}
      </div>
    );
  }
}

const mapStateToProps = state => ({ ...state });

const mapDispatchToProps = dispatch =>
    bindActionCreators({
        fetchWhiskies
    }, dispatch);

export default connect(mapStateToProps, mapDispatchToProps)(App);

As you can see, there's lots of modifications here. First we have to bind the Redux store and action creators to the component's props. We use the connect HOC from react-redux to do so. After that, we create a div which has a button whose onClick is set to call the fetchWhiskies action creator, now bound to dispatch. Clicking the button will dispatch the FETCH_WHISKIES action and our Redux Observable epic will pick it up, thus calling the API. Next we have a condition where if the isLoading property is true in the Redux store (the FETCH_WHISKIES has been dispatched but has neither completed nor thrown an error) we show a text saying Load data. If the data is not loading and there is no error we render the WhiskyGrid component and pass the whiskies from Redux as a prop. If error is not null we render the error message.

Conclusion

Going reactive is not easy. It presents a completely different programming paradigm and it forces you to think in a different manner. I will not say that functional is better than object-oriented or that going Reactive is the best. The best programming paradigm, IN MY OPINION, is a combination of paradigms. However, I do believe that Redux Observable does provide a great alternative to other async Redux middleware and after you pass the learning curve, you are gifted with an amazing, natural method of handling asynchronous events.

If you have any questions please ask in the comments! If this gets enough interest we can look into delaying and cancelling actions.

Cheers :)

Straightening out the React/Redux learning curve part 1 - Intro to React

Andrej Naumovski — Sat, 02 Dec 2017 23:48:48 +0000

Disclaimer: I'm writing these posts in multiple parts just so that it's better separated and so my conscience can bother me that I have to actually continue blogging.

Disclaimer 2: I will be using ES6+ syntax in the code I write because it's easier to read and it's a modern-day standard (it's also my personal preference to not use semicolons, sorry about that). If you aren't accustomed with ES6 I provide a link further down the post where you can find lots of resources to help you learn.

Disclaimer 3: All of the libraries I use in the code provided are available via NPM. I will not cover how NPM works in these series, so you should already have basic knowledge.

An introduction

React seems to be ever gaining in popularity. Despite all the new JS frameworks that are popping up, you keep reading about React and Redux on every developer website, blog, seminar. So you decide to check it out and see what the fuss is about. Or, if you're me, you came from a background of AngularJS/Angular 4 into your first actual job and on a React-based project. So you open up YouTube/Pluralsight/some other website with courses and tutorials to dive into the world of React. But 10 minutes into the first video and you've heard about actions, reducers, a store, components, state, higher-order components etc, and you're sitting there wondering "Am I just stupid or is this just overly complicated?".

The answer, it's complicated. At first sight.

It's complicated because it's different. Chances are, you've never seen anything like it, especially if you, like me, come with Angular experience. The structure in Angular is based on controllers (AngularJS)/components (Angular 2/4) and services. It resembles a back-end organizational structure, and it feels familiar to back-end developers (especially if you've ever worked with Spring, like I have). And it should make sense, since Angular 2 was targeting enterprise development.

Before I begin, I want to let you know that I didn't learn, or should I say, am not learning React simply because I want to, but because I had to. I started my first job 3 months ago, while still in university, where I was put on a React-based project. My only previous experience in front-end JavaScript development was AngularJS, and (more recently) Angular 2/4. I had to catch up with ES6+ first since I was using TypeScript, so if you haven't done that, I recommend to check out this link first. Anyways, I am writing these series as I am still evolving, in hopes that a beginner's opinion might help out other beginners who are just as lost as I was.

I did forget to mention that, even though I was kind of forced in learning React, I'm loving it more and more each day!

A couple of more notes and we will dive right into React (I promise!):

1. You will have to adapt to a different project structure. This is simply because React/Redux's core concepts do not exist anywhere else.
2. Don't get frustrated when you have to edit/create a lot of files for a single feature. This may be painful at the beginning, but it will save you time (and headaches) later, especially when debugging, trust me.
3. It takes time to adjust your mindset to React and Redux's workflow. As I mentioned before, React/Redux's concepts are different. Therefore, it will take you time before you'll be able to naturally think in terms of actions and reducers. It took me a month before I was confident enough to write a new component.
4. Doing an actual project outside of work using React/Redux helped me dramatically. It's different when you work on an already built project and when you have to build one on your own from scratch. Doing it from scratch helps you understand the concepts more thoroughly.

Diving into React (what is it, how does it work, what are components)

Going through the tutorial, I will use a question-answer based structure, by answering the questions I had when I first started learning React.

Okay, now that we got out of the way, we can start. So, first question, what is React?

React, on itself, is simply a JavaScript library for building UI components who can retain state.

-Sounds cool. What are components though?
Components are simply elements that you can render on the UI. They're built of base HTML tags and other React components. React splits the UI into multiple components so that you can, 1. reuse them and, 2. so that you can isolate each component's logic.

-Okay, I understand what components are. What does 'retain state' mean?
Retaining state simply means that React components can keep the state of the elements they contain, such as the current value of an input field. Angular accomplishes this using two-way data binding. In React, however, in the context of a single component, everything is stored in its state. An update to an input field should trigger an update in the state, which will re-render the component and update the input field with the new value from the state.

-Hmm, but isn't that kinda stupid? All those re-renders surely must have a performance impact?
No, because of React's Virtual DOM. I will not dive into how the virtual DOM works in these series, but the link I provided contains a really good description of it. You can check out performance benchmarks for multiple JS frameworks/libraries here. You can find links to benchmark results in the README.

-Okay, I get it, virtual DOM is pretty fast. Is there anything else I should know?
As a matter of fact, there is. I should probably tell you what JSX is, since you will use it to write your components. JSX is a preprocessor step that allows you to use XML-like syntax to write your components' look/structure, instead of using methods provided by React. For a more detailed guide on JSX and to see the difference of using and not using it, check this out.

-JSX looks a lot more readable than actually using React.createElement, sweet! How do I write my first component?
There's multiple ways you can write a React component. The most up-to-date way, however, is to use an ES6 class that extends the React.Component class, and that has a render() method. Like so:

//MyComponent.jsx
import React from 'react'

export default class MyComponent extends React.Component {
  render() {
    return <h1>Hello from my first component!</h1>
  }
}

And that's it! We just created a simple React component that renders a h1 heading. Notice that <h1></h1> tag? That's JSX at work. The JSX preprocessor will compile that into React's createElement method. You can see the differences in the link on JSX that I added earlier in this blog.

-Wow, awesome! But, wait, I'm confused, how do I render this component? Or better yet, how do I start my app at all?
We're getting there. In order to render your component and start your application you need a starting point for your application, like an index.js file. But in order to run ES6+ you'll need Babel etc. I'm getting headaches just by writing about all these configurations and boilerplate code. Luckily, there's a tool which will generate all of this for you. Cue create-react-app. For simplicity reasons, I will assume we have the application set up with create-react-app (it has a pretty great documentation), which should generate these files in the src directory:

App.css
App.js
App.test.js
index.css
index.js
logo.svg
registerServiceWorker.js

index.js is the starting point in our application. It replaces the element with id="root" in our index.html file with the compiled App component, which currently renders an autogenerated UI. The ReactDOM.render() method can have one and only one parent tag, which is why we will render all of our components (and routes, in the future) in the App component. First of all, add your MyComponent.jsx file in the same directory as the above mentioned files. Then, open App.js and modify it in the following way:

import React, { Component } from 'react'
import MyComponent from './MyComponent'
import './App.css'

class App extends Component {
  render() {
    return (
      <div className="App">
        <MyComponent />
      </div>
    )
  }
}

export default App

What we do here is import our exported class from MyComponent, and then add it as a child of the main div tag.

This will render our MyComponent component as part of the App component, instead of the previous generated content. React components can have other React components as children which, in turn, can have other React components as children etc. There is no limit to how you structure your components, which means you can reuse your components anywhere you'd like, and that's what makes React great.

We want to have a single component which renders the others because, as I mentioned, the render method we use in index.js can only have one parent tag.

Part 1 conclusion

I think that should be enough, for starters. I believe I covered most of the questions that beginners start to ask when first diving into React, and then gave a simple example of how a component looks like.

Wait, but I didn't see anything of the component state you talked about earlier!

That's exactly what we will do in part 2. We will cover component state in React and passing props to children. Please, I'm just starting out writing blogs, so if you have any suggestions for me, let me know in the comments section, it will be much appreciated. And stay tuned for part 2!

What having a programmer burnout at age 21 feels like

Andrej Naumovski — Wed, 08 Nov 2017 19:04:44 +0000

In my first post on dev.to I'd like to discuss what's it like to experience a common programmer/developer/software engineer problem at a very young age, very early into your career.

A small intro first, I'm 21 years old, currently in my senior year of university, majoring in Computer Sciences and Engineering. I've also started working part-time as a junior web software engineer two months ago, and as an undergraduate TA at my university. Seems a lot right from the start, doesn't it?

Seems like all this isn't enough for my brain. I can't seem to stand still for a moment, I have too many ideas and projects going on in my head at all times that I just have to start working on anything I find even remotely interesting - and end up regretting it later (the time of writing this is 'later'). On top of university, work, personal projects and (some vague form of a) social life, I also freelance.

In general, on a working day I (easily) spend 12+ hours working. This has been going on for the past couple months.

To sum all of this up, in a normal day I encounter different technologies and languages ranging from Spring to React to Node to Python, and spend a lot of time. And don't get me wrong, I like all of the tools I'm using, otherwise I wouldn't use them.

Anyways, I'm currently in the final stage of a freelance project I've been working on in the past couple of days, and I'm starting to feel like programming isn't even fun anymore for me. Like I don't even like doing this. I feel I am appalled by a framework and language I enjoy writing in on regular days. I blankly stare at my IDE, I know what I'm supposed to write, but I can't make myself write 200-300 more lines of code and just finish and deliver the project. In all honesty, I feel like s**t.

There's three reasons I'm writing this. The first is because I deeply feel I need to write this off somewhere and get it out of me.

The second one is to remind every developer that is currently starting their first job, and just getting into the field, to take it easy. Make balance. Make balance, because feeling burnt out and not even being out of college is, in my personal experience, without doubt the worst feeling ever. It's a part of your life you never want to be in, trust me.

And the third reason is to ask for advice. How have the lot of you dealt with programmer burnout before? How do you recover from it?