Skip to content

Instantly share code, notes, and snippets.

@gdpelican
Last active September 20, 2016 10:21
Show Gist options
  • Save gdpelican/6836ea24d504ed8faf37be1cda5b5d2d to your computer and use it in GitHub Desktop.
Save gdpelican/6836ea24d504ed8faf37be1cda5b5d2d to your computer and use it in GitHub Desktop.
Loomio migration to angular 2

Migration to 1.5

  • Upgrading 'directives' to components doesn't seem too hard, but is tedious and error-prone
    • Need to update all references to the inherent scope (so %div{model: 'thread'} needs to become %div{model: '$ctrl.thread'})
    • We can also rename '$ctrl' with the controllerAs option when creating the components
    • This has the benefit of allowing (small parts of) our views to port over to angular 2 (more on that later). However, in my view the views will still require a substantial rewrite on top of this, because the syntax from 1 -> 2 is so different

Migration to 2.0

  • Dependency support for angular 2: Ones I'm concerned about:

  • Updating the router will involve manually downloading the 1.x router from the angular 2 archive, and holding it there

    • although I've spent a lot of time complaining about the router, I think what we have is Good Enough until the 2.0 upgrade
    • The biggest failing I've run into with the current router is that $router.navigate('/dashboard') doesn't work, which crops up as annoying occasionally.
  • Coffeescript only barely supports module imports (jashkenas/coffeescript#3162 (comment)), which are key for angular 2. I don't really get why the maintainers have taken the stance they have on moving CS forward, but to me it says 'this thing is dead'. I recommend we move off coffeescript before taking the jump to angular 2. Options here are:

    • ES6 (aka ES2015): It's the 'official' javascript, and the one browsers will (eventually) support natively (meaning we won't need to transpile it the way we do now). It's got a bunch of neat features which coffeescript brought into the world, and we've been promised that it will get regular yearly updates of further fixes and features.
    • TypeScript: It's a Microsoft flavour of ECMAScript and has a superset of features from es6 (ie, there's nothing in es6 that isn't in TypeScript). The big difference is that it enforces static type checking, so you don't ever get a string when you're expecting an int. Angular itself is written in TypeScript, and as of now quite a bit of the documentation for how to use Angular 2 uses TS code samples (they will have examples in ES6 and Dart soon, though). I'm personally a little averse to static type checking, and I believe it's solidly a less widespread language than es6 is / will be.
    • Dart: I don't know that much about Dart other than it's an ECMAScript, and sometimes people lose their mind over it. It doesn't seem to be massively popular yet though, it won't have the kind of ecosystem TS / es6 will, and I think this would be an odd tech choice.
  • The controllers will all need to be rewritten, basically from scratch. (This would be the case equally whether we upgrade to angular 1.5 or not)

  • The views will need to be rewritten because the syntax for binding and declaring directives have changes

    • before: %a_directive{ng-if: "visible()", ng-class: "classes()", ng-model: "thread"}
    • after: <a-directive *ngIf="visible()" (ngClass)="classes()" [(ngModel)]: "thread" />

    I am concerned about haml's ability to handle angular 2 syntax effectively. I can't find anyone talking about it. We will need to try it out.

    (PS the in-element syntax for angular 2 is a mindfuck until you read this table: https://angular.io/docs/ts/latest/guide/template-syntax.html#!#binding-targets)

  • I don't quite know why, but ng-upgrade (http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-to-angular-2-using-ngupgrade.html) feels like crap to me. I'd be up for trying it out to learn Angular 2 syntax and some of the idiosyncracies (and maybe get some angular 2 code in prod for benchmarking), but once we're at that stage I say we whole hog and upgrade the thing.

Migration to React

  • This will be a full scale rewrite, so not something to be taken lightly
  • One approach might be to write a mobile client in React Native, then if we like it, simply using it for the web as well
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment