Suchit Puri

Recently i have been trying out the new kid on the block, React.js and its unidirectional data/state management partner Flux. The concept of React.js is very simple. Your app is a combination of react components.  Every component has a state and properties. Whenever there is any change in the state or properties of the components the component is rerendered. Though in the above points i used the state and properties very casually. Usually its very important to get your head around when to use state and when to use properties.  You can refer to this article  https://github.com/uberVU/react-guide/blob/master/props-vs-state.md  to find out more about props vs state.  On the other hand Flux which calls itself an architectural pattern rather than a framework, is also straight forward. There is a dispatcher whose main goal is to dispatch the event to all the registered objects. There is a store , the store basically encapsulates the state of a component or group of components. The store reg

Model objects, defined by the ember-data library abstracts away the complexities involved with handling the communication with the server, serializing, as well as de-serializing of the response received from the server. In order to define your ember-data model object, you just need to extend the DS.Model object present in ember-data module as follows: Models form the core of any MVC design pattern as they describe the core business domain at hand. In Ember.js, every route has an associated model that describes the business domain that the route needs to work on. Almost all of the examples that we have seen so far operate on the static data that is returned from the model property of the routes. But most of the times the data that needs to be operated upon is not static and is fetched from a remote server. Traditionally we have used jQuery or plain JavaScript to fetch the data from the server, using AJAX calls and then using those returned JSON objects as models in our application. This