Protiviti / SharePoint Blog

SharePoint Blog

December 18
Wrangling the Beast of ngRx

Last year, my team at Protiviti built an Angular 2 single-page-application and we decided to try an exciting new JavaScript library with it: ngRx. The short and sweet of it is that even though Angular 2 renders far faster than Angular 1, it still lags behind React, Facebook’s popular rendering engine. ngRx attempts to bridge this gap by implementing React’s “Flux” design pattern for Angular. If you’re unfamiliar, Flux allows you to only update pieces of the UI when their observed data changes, making your rendering very efficient. Unfortunately, I walked away from the project feeling unsure about ngRx. On one hand, I saw the potential performance gains and it also forces you to code in a clean, structured way that’s less error-prone than usual. On the other hand, I watched as my team and I struggled to get over the difficult learning curve and I couldn’t help but notice that even simple tasks required a lot more code with this pattern. I wasn’t sold on it. Anyway, I moved on to other projects and let ngRx sit in the back of my mind for a couple months. That brings me to this week. I’m in Chicago’s JavaScript Meetup group and this week, one of the talks was going to be about ngRx. This was my chance. For better or worse, I would have my catharsis!

The first talk was about another JavaScript library, RxJS, and this is actually really important for ngRx. The “Rx” in “ngRx” actually refers to RxJS, as ngRx is built around it. Here, I found my first problem. I simply didn’t have a good enough grasp on RxJS. I had used it throughout the ngRx project but I had no idea of how useful it could be. Every time I read an article on RxJS, it read like Doc Brown from Back to the Future rambling about how amazing streams are so a lot of it went over my head. This presentation finally slid things into place for me. RxJS really just provides you with all sorts of helpful utility functions, but forces you to look at things as observables or streams rather than discrete data, which can be a different way of thinking. That said, given how prevalent events and asynchronous actions are in modern JavaScript, and that those are perfect candidates for observables, this is absolutely a library worth your time. I would later find out that my main technical hurdle with ngRx could have been solved just by using an RxJS function…. D’oh!

So then came the ngRx talk. The moment I had been waiting for. And the speaker was ready for me too!

I chuckled out loud as I had had these exact debates with my teammates before. But he got right to it, not only being a fan of the library but also clearly having a mastery of it. Though he didn’t offer any earth-shattering revelations, he had a number of great suggestions for using the framework:

  • You don't have to use ngRx and Flux for every component. If a component doesn't have a lot of crazy UI rendering and has a simplistic state model, then you don't need to use it if you don't want to. This is also important, because this means you can add ngRx to your app after-the-fact and not have to worry about redoing the whole site
  • Implement a rigid folder structure, separating out your reducers, actions, effects, and selectors. This is critical as you scale
  • If you use the Redux dev tools, you can time travel your model for debugging, e.g. "what was the previous state?" I never used this, unfortunately, but I wish I had
  • He mentioned a concept called “smart & dumb components” that I really liked. This idea was popularized with React but fits perfectly with ngRx too. The idea is to separate your components into two types:
  • Smart Components: these know how things work, hold the reference to the state, call flux actions, etc. A "container component"
  • Dumb Components: these deal with how things look, have little if any state, minimal dependencies, etc. A “presentational component,” e.g. a footer of your page
  • Don’t use 2 stores. My team and I had talked about potentially doing this but the speaker said this is more trouble than it’s worth
  • Lastly, he demoed ngRx Effects. Here, he subscribed to an action (more RxJS) and was able to do some cool GUI stuff in response to the action

Though I still can’t say I’m a diehard fan of ngRx, this talk assuaged a lot of my concerns with the library. And to be fair, the speaker acknowledged the learning curve but countered it by saying he now feels he develops applications faster in the long run with ngRx: easier to alter plus less bugs and regressions. Anyway, I’m glad I was able to get some fresh perspective on ngRx and I hope these tips help you if you choose to give ngRx a try yourself. Thanks for reading.

Speaker’s Article that the presentation was based on:

Quick Launch

© Protiviti 2018. All rights reserved.   |   Privacy Policy