Book Image

Flux Architecture

By : Adam Boduch
Book Image

Flux Architecture

By: Adam Boduch

Overview of this book

Whilst React has become Facebook’s poster-child for clean, complex, and modern web development, it has quietly been underpinned by its simplicity. It’s just a view. The real beauty in React is actually the architectural pattern that handles data in and out of React applications: Flux. With Flux, you’re able to build data-rich applications that engage your users, and scale to meet every demand. It is a key part of the Facebook technology stack that serves billions of users every day. This book will start by introducing the Flux pattern and help you get an understanding of what it is and how it works. After this, we’ll build real-world React applications that highlight the power and simplicity of Flux in action. Finally, we look at the landscape of Flux and explore the Alt and Redux libraries that make React and Flux developments easier. Filled with fully-worked examples and code-first explanations, by the end of the book, you'll not only have a rock solid understanding of the architecture, but will be ready to implement Flux architecture in anger.
Table of Contents (21 chapters)
Flux Architecture
Credits
About the Author
About the Reviewer
www.PacktPub.com
Preface
Index

Testing action creators


Now that we have a rough idea of how Jest works, it's time to start testing the various components of our Flux architecture. We'll start with action creator functions, since these determine the data that enters the system and are the starting point of the unidirectional data-flow. There are two types of action creators we'll want to test. First, we have the basic synchronous functions, followed by the asynchronous ones. Both types of actions lead to very different types of unit tests.

Synchronous functions

The job of an action creator is to create the necessary payload data and to dispatch it to stores. So to test this functionality, we'll want the real action creator function and a mocked dispatcher component. Remember, the idea is to isolate the component as the single unit that's being tested—we don't want any side-effects from the dispatcher code to influence the test outcome. With that said, lets take a look at the action creator:

import dispatcher from '../dispatcher...