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

Keeping views stateless


Views can't be completely stateless because they interact with the DOM, and the DOM elements associated with a view will always have a state. However, we can take steps to treat views as stateless entities within the context of our Flux architecture. In this section, we'll address two aspects of stateless views.

First, we'll go over the idea that all state in a Flux architecture belongs in a store, including any UI state that we might be tempted to keep in our view components. Second, we'll look at DOM querying and why we want to avoid doing this from within our Flux views.

UI state belongs in stores

As you learned in the previous chapter, UI state is just like state that's derived from application data—it all belongs in a store. UI state includes things such as the disabled property of a button or the name of a class that's applied to a div. The reason these bits of state belong in a store is that other stores might depend on them. This in turn affects the rendering...