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

Passing views data


Views don't have their own data source that they can use to render UI elements. Instead, they rely on the state of Flux stores, and they listen for changes in state. In this section, we'll cover the change event that stores will emit to signify that views can render themselves. We'll also discuss the idea that it's ultimately up to the view to decide when and how to render the UI.

Data via the change event

The view components that we've seen so far in this book have all relied on the change event that stores emit when the state of a store has changed. This is how the view knows that it can render itself to the DOM—because there's new store state, meaning that there's probably a visual change that we want the user to see.

You may have noticed from the earlier examples that all the handler functions that listen for change events had a state parameter—this is the state of the store. The question is—why do we need to include this state data? Why can't the view just reference...