Skip to content

Dev Tools

JT edited this page Nov 9, 2016 · 24 revisions

Quick Overview

  • We want a stack that's fast and scale-able
  • Redux accomplishes this for us, in the following ways!
    • one-to-many relationship cycles instead of many-to-many nested relationships
    • immutable objects prevent random mutations (read only is faster, and more predictable)
    • introduces invaluable development tools for debugging (redux-logger, redux devTools)
    • Testing is simplified due to the nature of pure functions and functional programming

Our Reasoning

We at GOAT wanted to design a stack that would make it easy for developers to implement fast and scale-able web-applications. Most developers coming from angular understand the concepts of MVC, but with this architecture there are downfalls. With size, Angular(JS & 2) applications become entwined with many-to-many relationships between components, directives, and services. These nested relationships are very problematic, and quickly become Angular's worst enemy. This is why we have chosen to make Redux the point-man of our stack, to preserve a scale-able structure while maintaining the modular ideology presented by the Angular team.

The Redux Epiphany

With the Redux architecture we keep all of our business logic and app functionality inside actions which then call a dispatch to a reducer which changes the application store (this holds all the application's persistent data) to change a corresponding data structure. This way all the persistent data throughout the application is stored in a single place. This structure naturally makes the app (store) a data focal-point which facilitates one-to-many relationship cycles with Angular2 components. Another Redux philosophy is to use immutable data. This forces the application to create a new object in a different area of memory while letting the garbage collector take care of the old one. Mutating an object can often result in unexpected outcomes when changing bytes in memory. Creating an entirely new read-only object fixes this problem. Along with the passive advantages of read-only objects, this philosophy eradicates any possible random mutation that could potentially break your app.

With Redux, many developing advantages are adopted as well. Redux gives developers the ability to use plugins to help debug their application. Two invaluable ones are currently integrated within the GOAT-stack; redux-logger, and redux devTools. On every state change, redux-logger will log the state change in the console presenting the current state of the store, the action that will change the state, and the next state of the store. Inside each state is a snapshot of the store reflecting the data inside of it at that time. The next is redux devTools. This works very much like redux-logger in that it shows the state of the app as it changes. This tool works in conjunction with the redux devTool chrome extension which gives you the entire history of the application state changes and the ability to rewind the app to a previous state and playback history.

But wait, there's more!

Redux also makes client side testing effortless. Instead of using testBeds which essentially creates instances of the entire app.module, Redux embraces the concepts of pure functions and functional programming. And because components are now dumb this means that the actions and reducers do not depend on anything but themselves. So testing an action/reducer would only need an instance of that action/reducer, nothing more.

For more information on Redux and how awesome it is, visit here

If you want to learn more about the angular 2 implementation of Redux, visit here

Clone this wiki locally