# Architecture The Starter Kit architecture is designed to support scalable, modular applications. Built around [Redux](http://redux.js.org/), it makes it simple to reason about your application's state, and as a result to write maintainable, error-free programs. ### Redux The application state and state changes are managed by **Redux**, a library that implements a pure, side-effect-free variant of the Facebook [Flux](https://facebook.github.io/flux/) architecture. Redux and Flux prescribe a unidirectional dataflow through your application. To understand Redux, check out this [Cartoon guide by Lin Clark](https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207#.4dpmozm9v) (it's great, not a joke!) and [Dan Abramov's Redux course on egghead.io](https://egghead.io/series/getting-started-with-redux). Redux helps us with synchronous updating of our state, but it doesn't provide an out-of-the-box solution for handling asynchronous actions. The Redux ecosystem has many possible solutions for this problem. In our application, we use the vanilla redux-thunk middleware for simple asynchronous actions, and **redux-loop** to handle more complex asynchronicity. ### Organising code #### Components The `components` directory should contain React Native JSX components, which take their inputs in as `props`. In Flux/Redux parlance the components should be dumb/presentation components, meaning that components should not be `connect()`ed to the redux store directly, but instead used by smart/container components. The components may be stateful if it makes sense, but do consider externalising state to the Redux store instead. If the state needs to be persisted, shared by other components, or inspected by a developer in order to understand the program state, it should go in the Redux store. A component may be either written as an ES6 `class Foo extends Component` class or as a plain JavaScript function component. Usage of `React.createClass` should be avoided, as it [will be deprecated in 15.5](https://github.com/facebook/react/issues/8854) If a component implementation differs between iOS and Android versions of the application, [create separate `.android.js`and `.ios.js` files](https://facebook.github.io/react-native/docs/platform-specific-code.html) for the component. In minor cases the `React.Platform.OS` property can be used to branch between platforms. #### Containers The **Container** (or **View Container**) is responsible for `connect()`ing the View component to the Redux store. Redux `connect()` takes in two arguments, first `mapStateToProps` which selects relevant parts of the application state to pass to the view, and second `mapActionsToProps`, which binds Action Creators to the store's dispatcher so the actions are executed in the right context. These functions are often called *selectors*. We think using `mapStateToProps` is a good practice, but avoid using `mapActionsToProps` in favour of calling `dispatch`ourselves in the view. In our experience this leads to simpler, easier to reason about code (and a little less verbose PropTypes on the View). We also use `recompose` to give you an ability to manage state, lifecycle events and more inside your containers, not components. Check you the docs at --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.reactnativestarter.com/master/arhitecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.