React - Uniform management of state and time

The purpose of this thesis is not to introduce the full ecosystem needed to build applications in ReactJS but React itself and how to manage the State in React. React is not a full- blown framework and instead it is just a library with a single concern, that is the V (view) in MVC (Model View Controller). The objectives of this thesis theory part, is to shed some light into what is needed to develop React in the context of State management. What is React and what is it good for? What do you need to know about React’s own local State management or third-party State management libraries? To adhere the research questions, a study application was made. This application was contracted by HiQ for a Customer company, not to be disclosed in this thesis as a non-disclosure agreement was made with the Customer. This application was made with a high importance of State management within the requirements. This thesis goes through the phases of JavaScripts history and early development, which leads up from SPA (Single Page Applications) frameworks, to the current phase of modularity pattern as the most popular pattern of Client-side development. The history of React and the key points of React ecosystem, such as JSX, VirtualDOM and its local State management through modular patterns and architecture have become something of a standard in the Client-side developers community and through, such the management of State has moved towards the Client-side from Server-side. Flux is more of a pattern than a framework that was developed by Facebook, as an opinionated way to manage the State in unidirectional way. The emergence of Flux left the React community in disarray with multiple Flux implementations with their own way of implementing Flux pattern with incombabilities between them. Redux came to the sceen as Flux like library, with opinions how to manage the state with Functional programming paradigm, State-tree, Time-travel and HMR (Hot-Module-Reloading). Redux came as the de-facto tool how to manage the State in an opinionated way and the de-facto status of it stands to this day. MobX turned away from Flux in a hole hearted way with Reactive Functional Programming. The MobX library abstracts State management with reacting to changes in the data with traditional OOP concepts, which cut down the demanded boilerplate compared to other State management libraries. MobX achieves of being efficient in performance and time to develop by cutting down the time to develop applications. MobX-state-tree is a union of two paradigms of mutable and immutable. It is an extension library to MobX with more opionion of How than the parent library. An application was made as a proof-of-concept application to a Customer, to determine, if the MST library could be an applicable replacement option to Redux or MobX. The application was done following a loose agile development cycles, determining Customers needs. The application done was a true FullStack JavaScript application where the Client / Backend shared the same programming language and even the CSS styles were done with CSS-in-JS (CSS with JavaScript). MST accomblishes to structure the application with clear opinionated patterns and combines the best of the immutability and mutability paradigms. The libraries fate is sealed with the advancement of its parent library that is MobX. However, MST complements MobX library in a way that (in this thesis writers opinion) will add significant value to HiQ and its Customers