I've been thinking a lot about state and how to store data in Angular applications. Yesterday I gave a talk about unit testing in AngularJS and Angular 2. The people there are really liked the talk, but afterwards I learned that at the company whose office I was at (AWeber) they were creating all their new applications with React. I had seen a few high profile job postings mention React so even though I love Angular I wanted to not look like a fool in an interview. Also, I was curious how React components were similar and different from Angular components. And finally, I see the advanced Angular devs getting really excited about Redux so I wanted to figure out 1. what was so great about it, 2) why I would even want to use it in Angular, and 3) what the code looks like to actually use it! This post is just me getting my thoughts out as I try to understand React and Redux better. Maybe it could help you understand them better as well.
What is Angular Stuff and What is Just SPA Stuff?
People who only know Angular really love Angular. And sometimes they are afraid of other frameworks because they don't realize all of the similarities between the two. Here are some general good things to expect with when building a SPA:
- Components - Let's get the obvious one of out the way, they all deal with components. A component is basically markup (when it's angular jade, jsx, ember markup, etc) that is tied to some JavaScript (and of course you can substitute this with your newest favorite compile-to-JavaScript language).
- Routing - We are making "Single Pages Applications", yes, but we are still going to want to wipe the whole view and put up a new "page". We're still going to want to create new links in the address bar and take advantage of the back and forward buttons, SEO blah blah blah...
A great router is the Angular 1 UI-Router. Angular 2 is meant to have the capabilities (and possibly more?) of UI-Router thus making it a lot simpler with just one, standard router that works. Some features of good routing systems are that you can do nested routes and pass parameters with your routes. In angular you can use the service to hook into different methods and events on the router. - Command Line Workflow - Grunt, gulp, browserify, webpack, angular cli... There are almost too many task runners and applications bundlers to keep track of. Almost. :) However, once you are comfortable with one it's a pretty short ramp-up time to move to a new project as long as they have the same or similar functioning commands. A good workflow should have at least these commands:
- Runs your project in a browser with hot reload (ie updates browser on file changes).
- Runs your unit tests with hot reload,
- Runs your e2e tests.
- Build a production version of your application.
- Runs the production version in a browser so you can see and manually test it. - Testing - Ok, some people are rolling their eyes at me here. People know that I'm a huge fan of unit and protractor testing. Although there are some differences in how you "bring in" your components to be tested, unit testing applies to any application regardless of the framework you use. I'm pretty sure you can even use protractor to test React applications. And contrary to what the Angular team tells you, it's not that difficult to test applications without DI.
Is React a Framework or Not?
Some people will say that, "React is just the view". Yeah, that's kind of true, but when a project uses React people almost have to refer to it as a, "React Project". In real-world production applications you'll almost never see React mixed with Angular or another hardcore SPA framework (someone please correct me here). When looking to join a new company you'll often hear things like, "we have a React app" or, "it's an angular 1.4 app". This makes we think that React is more than just a library. It heavily influences how you structure you application and provides some magic so your files can interact with each other.
Is Dependency Injection Redundant?
One of the things I didn't really like when first starting with React is all of those import statements. Ew, what are they doing in JavaScript? Then in Angular 2 I started playing around with a TypeScript project, and there they are again! Ok ok, I get it. You import the components you need so that you have access to them in that file. But then is dependency injection really necessary here? In Angular 1 it made sense, but now it seems like React is able to do basically the same thing without the "extra" DI step. Does anyone else think declaring your imports and then declaring it for DI feels redundant?
The Redux Attraction
What's so special about Redux? Well, in React you can't make service components that can be stuck in anywhere you like (or can you?). In general, there is some top-level JavaScript object that holds the "state" of your application. I've talked about doing this with a simple object as a property of a "DataHolder" service in Angular. However, even in Angular I see people getting all hyped up about Redux. They say it's, "good for large applications". For a very long time I was resistant to any type of Flux pattern because I wanted to keep it simple. I felt that it was just unnecessary. But then I heard something that made me think. Someone said, "With your mutable DataHolder service technique, when a piece of information in it changes you don't know what changed it". Hmm. I've been thinking about this for a while and it is true. I'm not totally convinced how useful knowing where your state was changed would be for all projects, but I could see it being useful in certain cases (like if you are debugging something where you don't know why the state is changing to it's current value!).
Similarities Between Redux & MMO Game Backend Communication
Back in the good 'ole Flash days I had worked on a lot of online multiplayer games. There was always a lot of messaged being sent and received between the front and backend. Regardless of whether it was a Java backend on Electroserver or the C# Player.io / Yahoo Games / whoever owns it now, the API was similar- a string and an object with parameters. For example, here's an example from the backend C# code for how you send a message to a client:
player.Send("SCORE_UPDATE", player.score);
To me this looks eerily similar to one of your front-end components dispatching an action in an application that uses Redux. Instead of reaching into your DataService object and just updated the a variable you would dispatch the action, and let a special function (called a reducer) handle that action by making a deep copy of your state object, modifying the new object as needed, and then telling redux to use the new object as your store.
RSS Feed