Dev

How to embed Vue.js & Vuex inside an AngularJS app... wait what?

Feb 12, 2017

Since launching Cushion a couple years ago, we’ve been using AngularJS (1.x) as our front-end framework. If you’re curious how we ended up with Angular, I wrote about the decision (keep in mind this was 2014). I came from an MVCS background, so Angular really resonated with me, and it has served us well this entire time. Recently, however, with our improvements to the scheduling graph, we reached a point where performance has become an issue.

In previous attempts to improve performance, I found myself using lodash’s lightweight template function within Angular, which made me feel like I was cheating on Angular. In times when performance was absolutely crucial, I had to write raw JavaScript, which I have no problem writing, but it’s not exactly ideal for quick prototyping or iterating.

Now that our next big feature is time-tracking, I wanted to take this opportunity to try a new approach. What’s exciting this time around is that 1) there’s this new thing called the virtual DOM, and 2) almost every modern framework has adopted it. I was eyeing React last year (because my west coast friends wouldn’t stop raving about it), but it never really resonated with me—especially once you get into the whole Flux, Redux, Muppetdux, Hufflepux thing (those last two aren’t real). At one point, React was the only option if you wanted the performance of a virtual DOM, but one-by-one, every other framework caught on. Now, there are faster frameworks and some with a more familiar syntax to what I’m used to—like Vue.js.

I tried Vue a very long time ago, before it was even 1.0. The creator, Evan You, borrowed a few ideas from Angular and had a similar syntax, so Vue felt like a younger brother to Angular—a lightweight alternative, but not quite there yet. Because of its solid grounding, I chose Angular. While I started building Cushion on Angular, Evan began working full-time on Vue. Fast-forward several years and Vue is the new hot framework. It also feels much more solid than when I previously tried it, and it’s incredibly fast because of the virtual DOM—perfect timing for me.

I gave Vue another shot and was immediately blown away by how powerful it is while still so easy to use. I also appreciated all the nice touches that were added, like shorthands (@click instead of v-on:click) and event modifiers (@click.prevent to call event.preventDefault). Vue is now the lightweight alternative I’ve been searching for, and more importantly, it immediately makes sense to me.

The problem now is that I have years of code written with Angular and there’s absolutely no chance of me taking the time to replace Angular in one shot—especially if I want to make any progress on actual features. As a first step, I wondered if I could take advantage of Vue’s speed by replacing Cushion’s graphs with Vue components. I reached out to Evan—would it be possible to “embed” a Vue component within Angular? Apparently, yes! Evan pointed me to this article that suggests wrapping the Vue component with an Angular directive and using the ng-non-bindable directive to tell Angular not to interact with Vue’s HTML.

I tried using this technique and it does, in fact, work... but it’s not ideal. If I ever wanted to communicate between Angular and Vue, I would need to trigger Angular’s $apply method with every change within the Vue component. While this would be possible with some inconvenience, it didn’t feel right. Even though I could do it, doesn’t mean I should do it. The same could be said about embedding Vue within Angular, but I wasn’t ready to give up. I had one last idea.

Similar to React’s Redux, Vue has its own state management library—Vuex. Vuex keeps the app’s state in a centralized store rather than in the components. In my previous Angular/Vue experiment, Angular would’ve been the centralized store, as long as I called $apply with any changes—and I could only send data to Angular through the directive. With Vuex, a new possibility presented itself—what if I built time-tracking as a Vue app within Cushion? (I know this sounds so wrong, but hear me out.)

Without using Angular’s state management or http services, it serves simply as a router in Cushion. And considering Cushion’s tabbed navigation structure, I could contain an entire app in one of its tabs. Vue’s view model instance is incredibly lightweight and performant, so when a user switches to the time-tracking tab, Cushion can mount the instance and make any requests to the API from Vuex. Then, when the user navigates to a different section, Cushion can destroy the instance and clean up any loose ends. At this point, I no longer need to write hypothetically because I actually did this and it works really well.

I decided to go a step further. At its core, Vuex is simply a JavaScript object that stores data. What if I wanted more than one Vue instance to communicate with each other? For example, if a user starts a timer in the time-tracking section of Cushion and navigates to another part of the app, I’d still want them to know there’s a timer running. As long as Vuex is still available for the timer, I could destroy the time-tracking instance and mount another instance for the timer. Apparently, it couldn’t be simpler.

In Angular, there are providers, which are by far the most confusing aspect of Angular. (After three years writing an Angular app, I still need to reference the documentation for these, and they still confuse me.) One of these providers is called a “service”, which can be used to create a single store to reference throughout the app. All it needs is a function that returns an object. With a single line of code, I can return Vuex as an Angular service. Now, I can reference the Vue app’s state across the rest of Cushion and inject it into any Vue instance by simply specifying the store. On top of that, this opens up a way for me to migrate Cushion from Angular to Vue in steps, rather than rewriting the entire app all at once.

When we’re ready to start migrating other sections of Cushion, I can start treating each section as an app. I could rewrite the Angular controllers as Vue instances, and simply create new store modules in Vuex. Everything remains modular, and I wouldn’t abuse $rootScope as much as I do right now. Eventually, I’d be able to replace Angular’s router with Vue’s router and shake all the excess weight.

So far with Vue and Vuex, I’ve been able to create a much more clearly defined app structure, with state that “can only be mutated in a predictable fashion” (to quote the Vuex docs). I’m also taking this opportunity to ween myself off CoffeeScript in favor of ES6. As long as I’m improving one aspect of my dev life, I might as well kick another habit.


Learn more about Vue & Vuex.

Share this on Twitter or Facebook

Archive

  1. Our First Company Lunch
    Story
  2. How to embed Vue.js & Vuex inside an AngularJS app... wait what?
    Dev
  3. Funding Cushion
    Story
  4. Hiring a Team of Freelancers
    Story
  5. Taking a Real Break From Work
    Story
  6. Slack as a Notification Center
    Dev
  7. Document Your Features
    Story
  8. 300
    Story
  9. Vacations
    Design
  10. Offering Discounts
    Design
  11. Waves of Traffic
    Story
  12. Less Blogging, More Journaling
    Story
  13. Retention Through Useful Features
    Design
  14. The Onboarding Checklist
    Design
  15. Spreading the Word
    Story
  16. From Beta to Launch - The Subdomain
    Dev
  17. From Beta to Launch - Sign up
    Design
  18. From Beta to Launch - Messaging
    Design
  19. Launch
    Story
  20. Authenticating with 3rd Party Services
    Dev
  21. Intro to Integrations
    Design
  22. Inspiration vs Imitation
    Story
  23. The Emotional Rollercoaster
    Story
  24. Designing Project Blocks
    Design
  25. Everything in Increments
    Story
  26. Deleting Your Account
    Design
  27. Designing the Subscription Page
    Design
  28. Rewriting the Timeline
    Dev
  29. Restructuring the Individual Project Page
    Design
  30. Project Blocks
    Story
  31. Redesigning the Homepage
    Design
  32. Multiple Timelines
    Design
  33. Archiving and Estimate Differences
    Design
  34. Multiple Financial Goals
    Design
  35. Zooming in on the Timeline
    Design
  36. Currency
    Dev
  37. Preferences, Accounts, and a Typeface Change
    Design
  38. Sending Out the First Email
    Story
  39. Currency Inputs, Notifications, and Invoice Nets
    Design
  40. Dots and Lines
    Design
  41. Calculating in the Database and Revealing Tendencies
    Dev
  42. Improved Form UX
    Design
  43. Cushion is Online
    Story
  44. Schedule Timeline Patterns
    Design
  45. A Slimmer Schedule Timeline
    Design
  46. The Schedule Timeline
    Design
  47. Plugging in Real Data for the First Time
    Design
  48. Transitions and Project Lists
    Design
  49. Death to Modals
    Design
  50. The Individual Project Page
    Design
  51. Estimated Incomes and Talks with Other Freelancers
    Story
  52. Statuses to Lists and the Paid Beta
    Story
  53. The Timeline
    Story
  54. Invoice Terminology
    Dev
  55. Modal Forms
    Dev
  56. Wiring the Backend to the Frontend
    Dev
  57. Balancing Design and Dev
    Story
  58. Timecop, Monocle, and Vagrant
    Dev
  59. Going with Ruby and Sinatra
    Dev
  60. Ditching local-first and trying out Node.js
    Dev
  61. Switching to AngularJS
    Dev
  62. Building the Table with Vue.js
    Dev
  63. Clients, Projects, and Invoices
    Dev
  64. Introduction
    Story

Ask a Freelancer

A podcast series where experienced freelancers answer questions about freelancing.

Listen to the Podcast

Talking Shop

An interview series where we talk to freelancers about important topics in the freelance world.

Read the Interviews

Running Costs

Take a close look at the costs that go into running a web app and why we use specific services.

View the Costs

How It’s Made

Follow along with the journal for insight into the overall experience of building an app.

Read the Journal