Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ReactRally: Migrating Critical Apps to React

ReactRally: Migrating Critical Apps to React

Jamis Charles

August 25, 2015
Tweet

More Decks by Jamis Charles

Other Decks in Programming

Transcript

  1. Migrating critical
    apps to React
    Optimizing for change
    @jamischarles

    View full-size slide

  2. UI Engineer
    Send Money
    I’ve been at PP for 14 months.
    I’ll be talking about lessons learned when we starting
    to gradually move to React.

    View full-size slide

  3. Back
    Lets go way back

    View full-size slide

  4. 2014
    In 2014 when I joined the team, the
    Send Money flow looked like this…

    View full-size slide

  5. C++
    XML Markup
    C++ on the Server side, and custom XML Markup on
    the client.
    Our team’s charge was to build & roll out the new
    Send Money experience, which looked like this…

    View full-size slide

  6. Server
    {Dust.js}
    Client
    Kraken.js
    BB
    We were now on a modern stack with Kraken.js/node on server, and Require.js,
    BB, and Dust.js for templating on the client.
    We’d ramped to 5% in the US when I joined. In the coming months we ramped to
    100% in US. Things worked well for a while.
    We liked that Dust allowed us to use same template on the Server and the
    client. This came in handy when we moved from a server app to an SPA.
    Stack worked well for a while… Until our team had a hackathon to improve how
    fast the flow felt.

    View full-size slide

  7. As we started ramping up this new flow, we now had to support
    two flows that had different Views and templates, but shared
    a lot of common model logic. This became very ugly very fast.

    View full-size slide

  8. • too many abstraction layers
    • low confidence
    • difficult state bugs (currency codes mismatched
    etc)
    Pain
    Some of the pain we felt was… State bugs happened especially
    as you would navigate back and forth in the flow.

    View full-size slide

  9. Lets look at the abstraction layer problem. Say we
    want to change the AUD value in this list to AUY.

    View full-size slide

  10. Template.dust -> BB_view.js -> BB_model.js ->
    Route -> Node_controller -> Node_model ->
    Service API (SEVEN LAYERS)
    This feels like swimming upstream in order to find
    where this state is coming from. SEVEN LAYERS. This
    is crazy. Each of these jumps is a gap that you can
    fall into and get lost.

    View full-size slide

  11. This is a very poor DX. Really bad state to be in.
    But we have to balance this pain with the fact that
    we have…

    View full-size slide

  12. 100 million users in
    more than 100 countries
    We have 100M users in over 100 countries. We can’t
    just up and change stacks and break things whenever
    we want to. We have to be responsible and have the
    appropriate amount of rigor.
    So what to do? We started exploring other options.

    View full-size slide

  13. We started looking at Ember. We really liked how opinionated it was. It provided
    a lot of structure that our app was missing.
    React looked really interesting as well, but we just didn’t know enough about it
    yet.
    We experimented a little bit with Ember.
    And then we started seeing tweets about Ember from somebody in the community.
    I’ve blurred out the name to protect his identity.

    View full-size slide

  14. And then it turned into a total flame war

    View full-size slide

  15. This next one is probable my favorite.

    View full-size slide

  16. I don’t know if this is an endorsement, or criticism lol.

    View full-size slide

  17. They seem to have made up now…

    View full-size slide

  18. We had looked at Ember. Now we wanted to look at react.
    ReactConf came along several weeks later.
    At this point we’d done our homework with React. We’d done some research. We’d
    hacked together a few proof of concepts.
    We were thinking about sending a few devs to EmberConf or to ReactConf.
    The reality was, that ReactConf came first, so we went there.

    View full-size slide

  19. ReactConf
    5 of us went to ReactConf. It was really exciting. We were most excited by the
    fact that Facebook had had a lot of the same problems we were currently having
    and it seemed that React was solving these problems for them.
    We loved the focus on functional styles and principles. We realized that these
    principles would likely solve most of our problems.
    We completely bought into the ideas behind react.
    SIMPLIFY state.
    Immutable data.
    Functional principles. We could start doing these now.
    LETS TRY REACT!!!

    View full-size slide

  20. Gaining momentum
    In a big org, it can take a lot to change things. We sat down and looked at what
    needed to happen. Immediately we identified our biggest blocker…

    View full-size slide

  21. i18n
    How many people here use i18n? Here’s how it works for us.

    View full-size slide

  22. # note_en-US.properties
    note.title=Add a note
    note.placeholder=You can enter a note here.
    # note_de-DE.properties
    note.title=Notiz
    note.placeholder=Bitte schreiben Sie eine Notiz
    +
    {! note.dust !}
    {@message type="content"
    key="note.title"/}
    =
    // note_en-US.js
    var template = 'Add a note';
    We have a properties file that contains localized content by country. For the
    notes widget, somebody who speaks en in US will see the above. German in Germany
    will see the content underneath. The content is merged with the dust template,
    which generates a localized JS file by locale, that is loaded via require.js and
    rendered via dust.js. React can’t read .properties files, and we couldn’t change
    this, so we had to convert these to .json files.

    View full-size slide

  23. {
    // note_en-US.json
    note.title: Add a note",
    note.placeholder: You can enter a note here.,
    // note_de-DE.json
    note.title: Notiz,
    note.placeholder: Bitte schreiben Sie eine Notiz
    }
    import React from 'react';
    import { i18n } from 'react-i18n';
    let Note = React.createClass({
    mixins: [i18n('sendMoney/note')],
    render() {
    return (

    {this.i18n('note.title')}

    );
    }
    });
    export default Note;
    We created a Grunt task to convert prop files to .json

    View full-size slide

  24. {
    // note_en-US.json
    note.title: Add a note",
    note.placeholder: You can enter a note here.,
    // note_de-DE.json
    note.title: Notiz,
    note.placeholder: Bitte schreiben Sie eine Notiz
    }
    import React from 'react';
    import { i18n } from 'react-i18n';
    let Note = React.createClass({
    mixins: [i18n('sendMoney/note')],
    render() {
    return (

    {this.i18n('note.title')}

    );
    }
    });
    export default Note;

    View full-size slide

  25. import React from 'react';
    import { i18n } from 'react-i18n';
    let Note = React.createClass({
    mixins: [i18n('sendMoney/note')],
    render() {
    return (

    {this.i18n('note.title')}
    h2>

    );
    }
    });
    export default Note;
    Next we created an i18n mixin based on react-intl.

    View full-size slide

  26. import React from 'react';
    import { i18n } from 'react-i18n';
    let Note = React.createClass({
    mixins: [i18n('sendMoney/note')],
    render() {
    return (

    {this.i18n('note.title')}
    h2>

    );
    }
    });
    export default Note;
    Here you see how we require the mixin, we load it and specify the location of
    the content file, and then insert the content we want into the template. We have
    some magic that determines what country you’re in and which language you should
    see.
    Great. So now i18n works. At this point we only have one more issue.

    View full-size slide

  27. Require.js
    How many people here are on Require.js? Webpack? Something else? Who doesn’t us
    a module loader at all?
    There were 2 big issues with Require.js.
    1) Client side dependencies for testing was hard with mocha
    2) React is really built around the NPM ecosystem. If you want to experiment
    with Flux, Alt or Redux this is really painful to pull down and try out with
    Require.js.
    It’s really easy with…

    View full-size slide

  28. Webpack
    Jamund Ferguson, from my team moved us over to Webpack. He wrote a great post
    about this on the PP Engineering blog. You should go read it.
    The actual migration was about 2 days worth of work. He then issued a PR and it
    was open for a few weeks while we tested and reviewed it.
    We all loved it…

    View full-size slide

  29. Why were we happy with Webpack?

    View full-size slide

  30. Webpack
    • client-side require() npm modules
    • common.js
    • jsx
    • es6
    The biggest thing was that we could now use client side npm require(). Everybody
    loved that.
    We could now use common js on the clientside.
    We could use Babel-loader which made it really easy to start using JSX and ES6.
    We were able to preserve all of our old amd code, w/o updating or changing, but
    also start using new great features like es6 and jsx.
    The new & old could live in harmony.
    That makes everybody happy because of cost of trying new things is low

    View full-size slide

  31. You might think: Do I have to do all these infra changes before I can move to
    react? (pause)
    The fact is, you should be doing these things anyway.
    At this point this is best best practices.
    This will improve your existing workflow.
    Let’s see an example: We can start using es6 modules now.

    View full-size slide

  32. AMD vs ES6 imports

    View full-size slide

  33. define([
    'backbone',
    'view/currencyCode',
    'view/forms',
    'view/InternationalMoney'
    ], function (
    Backbone, CurrencyCodeView, Forms, IntlMoneyView) {
    return function populateCurrencyCodes (country) {
    var view = currencyCodeView;

    View full-size slide

  34. define([
    'backbone',
    'view/currencyCode',
    'view/forms',
    'view/InternationalMoney'
    ], function (
    Backbone, CurrencyCodeView, Forms, IntlMoneyView) {
    return function populateCurrencyCodes (country) {
    var view = currencyCodeView;
    We’re pulling in a currencyCode view file…

    View full-size slide

  35. define([
    'backbone',
    'view/currencyCode',
    'view/forms',
    'view/InternationalMoney'
    ], function (
    Backbone, CurrencyCodeView, Forms, IntlMoneyView) {
    return function populateCurrencyCodes (country) {
    var view = currencyCodeView;
    and assigning it to the CurrencyCodeView varible

    View full-size slide

  36. define([
    'backbone',
    'view/currencyCode',
    'view/forms',
    'view/InternationalMoney'
    ], function (
    Backbone, CurrencyCodeView, Forms, IntlMoneyView) {
    return function populateCurrencyCodes (country) {
    var view = currencyCodeView;
    which is now magically available in this inner function.
    Now let’s see the es6 version.

    View full-size slide

  37. import Backbone from 'backbone';
    import CurrencyCodeView from 'view/currencyCode';
    import Forms from 'view/forms';
    import IntlMoneyView from 'view/InternationalMoney';
    export default function populateCurrencyCodes (country) {
    var view = currencyCodeView;
    };
    This is so simple. You can see which file is being loaded, and what variable its
    export is being assigned to.
    You can also see down below very easily what is being exported from this file.
    This is so clear. Import and export. It’s great.

    View full-size slide

  38. import Backbone from 'backbone';
    import CurrencyCodeView from 'view/currencyCode';
    import Forms from 'view/forms';
    import IntlMoneyView from 'view/InternationalMoney';
    export default function populateCurrencyCodes (country) {
    var view = currencyCodeView;
    Here’s the full example.
    Now, let’s talk about lessons we leared when we issued our…

    View full-size slide

  39. First Pull Request
    At this point the infrastructure was in place. Everybody was excited. But what
    should our strategy be moving forward?

    View full-size slide

  40. Rewriting our whole app at once is a non-starter. It’s just not feasible. It
    would be too time consuming and far too risky. It’s a 3 page flow but there’s a
    lot of edge cases that you have to consider.
    So we decided to move over one small feature.
    What feature? What’s a good candidate? Everything on this page is really
    important. Let’s keep moving.

    View full-size slide

  41. What’s the least important feature? This is a really important point. If we’re
    going to screw something up when we push this to prod, we want do screw up the
    note you send along with the transaction. We DO NOT want to screw up who you
    send money to. We also DO NOT want to screw up the amount. If you want to send
    your friend $100 but we charge you $1000 this is a VERY BAD situation.

    View full-size slide

  42. This note widget is also complex enough to be a great candidate. It has
    localized placeholder content. It has some JS functionality that resizes based
    on content. And there’s a character counter.
    So my wife went out of town for the weekend and I decided to moved over the note
    widget to React. I issued the first PR. Here’s what it contained:

    View full-size slide

  43. First React PR
    • Dust template -> react/jsx
    • decoupled resize logic from BB
    • wrote tests for resize code
    • added __tests__ folder next to the code
    • changed testing helpers to work with __tests__
    This got merged instantly right?

    View full-size slide

  44. Sat open for two months
    What should I have done instead? The PR should have been much simpler.

    View full-size slide

  45. First React PR
    • Dust template -> react/jsx
    • decoupled resize logic from BB
    • wrote tests for resize code
    • added __tests__ folder next to the code
    • changed testing helpers to work with __tests__
    All that really needed to change was the template and the event binding logic.
    But I got really excited and wanted to experiment. I created way too many
    decision points for my peers when they reviewed this PR. We needed to have a
    meeting to discuss all these new patterns.
    None of these things really mattered yet.
    So the lesson here is…

    View full-size slide

  46. Keep first PR dead
    simple
    Next point I want to talk about is…

    View full-size slide

  47. Optimize for future
    change
    It’s only been 2 years since we chose our initial client side stack. 2 years is
    a short time to completely swap out your stack.
    So we have to ask ourselves ‘how can we reduce the cost of switching’?
    Around this time I found this great quote.

    View full-size slide

  48. – Michael Feathers
    “You have to build a barrier between yourself
    and the framework.”
    Michael Feathers wrote a great book called ‘Working Effectively with Legacy
    Code’. Most of deal with legacy code. What does this mean?
    If you only take one thing away from my talk, let it be this:

    View full-size slide

  49. – Jamis Charles
    “Use as much vanilla JS as possible.”
    By all means, still use React, React Router, Flux. All these are great and solve
    very specific problems. Beyond that really try to keep it framework agnostic.
    The problem we have right now is that everything is really tightly coupled. This
    prevents us from changing.
    Let’s take a look at an example from that notes widget.

    View full-size slide

  50. define(['jquery', 'backbone'],
    function ($, Backbone) {
    return Backbone.View.extend({
    el: 'form',
    events: {
    'keyup #note': 'resizeTextAreaField',
    'blur #note': 'hideTextAreaCounters'
    },
    // Resize text area as user types
    resizeTextAreaField: function (event) {
    var count = this.countTextContent();
    var newHeight = this.getIdealTextAreaHeight(count);
    var newRows = this.getRowsFromHeight(newHeight);
    $('#note').height(newHeight).attr('rows', newRows);
    },
    // Update textarea counter with remaining character left
    hideTextAreaCounters: function (event) {
    // pseudo code
    },
    So what are the important pieces here?

    View full-size slide

  51. define(['jquery', 'backbone'],
    function ($, Backbone) {
    return Backbone.View.extend({
    el: 'form',
    events: {
    'keyup #note': 'resizeTextAreaField',
    'blur #note': 'hideTextAreaCounters'
    },
    // Resize text area as user types
    resizeTextAreaField: function (event) {
    var count = this.countTextContent();
    var newHeight = this.getIdealTextAreaHeight(count);
    var newRows = this.getRowsFromHeight(newHeight);
    $('#note').height(newHeight).attr('rows', newRows);
    },
    // Update textarea counter with remaining character left
    hideTextAreaCounters: function (event) {
    // pseudo code
    },
    The event binding, and the business rules that control how the textarea grows
    when a user is typing in it.
    But what really needs to change when we move this from BB to React?
    1) The event binding.
    2) We have to decouple the business logic.
    Let’s see what that looks like

    View full-size slide

  52. define(['jquery', ‘backbone’, ‘utils/resizeTextareaUtil’],
    function ($, Backbone, ResizeUtil) {
    return Backbone.View.extend({
    el: 'form',
    events: {
    'keyup #note': 'resizeTextAreaField',
    'blur #note': 'hideTextAreaCounters'
    },
    // Resize text area as user types
    resizeTextAreaField: ResizeUtil.resizeField,
    // Update textarea counter with remaining character left
    hideTextAreaCounters: ResizeUtil.hideTextArea,
    };
    });
    We now have moved our business logic into a vanilla file called
    resizeTextAreaUtil. We can easily require that into this file, and still bind
    this with BB events. We can also easily require that into a React component and
    bind that to some React event. This can now be used in future framework versions
    without having to change.
    Reality: If you don't build a barrier, your legacy React code in 2 years will be
    just as painful to migrate as your current legacy BB code is now.
    So you’ve made it easier to change. What’s left? How do you convince people?

    View full-size slide

  53. Culture
    How many people are on React? How do people generally react to change?

    View full-size slide

  54. “Don’t make us switch AGAIN”! We just moved 4 months ago.
    So what we have to do is…

    View full-size slide

  55. Reduce the cost of
    change
    If we reduce the cost of change, you'll get a lot less pushback. Less tightly
    coupled.
    Our Culture at PP is receptive to new stuff. If we want to move again in 2
    years, I’m confident that we’ll do that.
    Next we’ll talk about things we did that worked.

    View full-size slide

  56. Worked
    • Conferences
    • Hack sessions over lunch
    • Distribute the work
    • Don’t alienate the last architect
    • Keep momentum
    Jamund did the infra. I did the React part.
    Have a very unifying effect. Excitement.
    Great to show off React, port things over, and address concerns. Watch videos.
    Work with him. Don’t say “this sucks we have to change”. Say “this piece is
    working, this other piece really isn’t working. Let’s fix that”.

    View full-size slide

  57. In Conclusion
    Make sure to…

    View full-size slide

  58. Solve real problems
    What pain points are you fixing?
    This is all really new and cool stuff.
    Story: At my last job at FamilySearch I wanted to drop jQuery. I’d read a bunch
    of articles and it sounded like a good idea. I was talking to the other
    engineers about it and they said:
    “PLEASE don’t make us learn something else. We’re overwhelmed enough with our
    current stack”.
    That brings me to my final thought.

    View full-size slide

  59. The principles that you learned here at React Rally are to help you solve real
    problems. If you don't have pain, don't make your team suffer. If you are facing
    problems, you can start applying these solutions we talked about today with or
    without react.

    View full-size slide

  60. Sources
    • Moving from Require to Webpack 

    https://www.paypal-engineering.com/
    2015/08/07/1450/
    • FE Masters React Course

    https://frontendmasters.com/courses/react/

    View full-size slide