Swizec Teller - a geek with a hatswizec.com

    Backbone → React – Step 1

    It’s happening! We’re moving Yup to React! ??

    We’ve got 37,380 lines of Backbone and Handlebars JavaScript with architectural roots reaching as far back as 2013. Since then, there’s been a pivot, some ebb and flow of different engineers, and more fundamental product changes than you can shake a stick at.

    We’ve had a bug for the past 4 or 5 months that everyone on the team and every user has seen. We’ve even got in-the-wild video recordings of it, but nobody has been able to reproduce it reliably enough to even begin debugging it, let alone fix it.


    After many months of poking and prodding and cajoling and covertly moving our codebase from ES5 to ES6, I got the green light to embark on an epic re-architecture refactor adventure. The refactor to end all refactors. The update to take us to infinity and beyond.

    No pressure. ?

    Of course, this refactoring can’t endanger the product roadmap, slow down the team, or cause any sort of inconvenience for the business.

    That’s right. For the foreseeable future (possibly forever?), the React and Backbone parts of the code have to live together in harmony.

    To get things started, we’re going to limit this Epic Refactor™ to a small, 7,100-line part of the codebase. That’s not terrifying at all! I mean, what could possibly go wrong™?

    Proof-of-concept for views

    Today, I built a quick proof-of-concept for how we can put large swaths of existing code into an otherwise React application. React is going to become the main part. Less React than Backbone at first, but React will be taking over the orchestrating of what renders when and how and where.

    Right now, our app is built out of Backbone views like this:

    class BackboneButton extends Backbone.View {
    constructor() {
    this.model = new Backbone.Model({
    N: 0,
    this.events = {
    "click button": "buttonClick",
    this.template = Handlebars.compile("<button>Clicked {{N}} times</button>");
    this.listenTo(this.model, "change", this.render);
    render() {
    buttonClick() {
    const N = this.model.get("N");
    this.model.set({ N: N + 1 });

    This is a typical Backbone pattern. You have a model that holds some state, a Handlebars template that puts variable values into HTML, an events hash, and a change listener. The user clicks a button and triggers a jQuery event, which calls the buttonClick callback. buttonClick updates the model, which triggers a change event. This triggers a component re-render, which inserts updated HTML into the page.

    It’s reactive and almost functional. Pure beauty. Not so great in practice… it’s kind of a mess. Don’t believe me? Re-read the 2nd paragraph about Heisenbugs.

    The first step to using these views in a React app is a wrapper that looks like this:

    class ButtonWrapper extends React.Component {
    button = new BackboneButton();
    componentDidUpdate() {
    componentDidMount() {
    _render() {
    render() {
    return (
    <p>Backbone Button:</p>
    <div class="button-anchor" ref="anchor">

    Our React component that doesn’t do much: it renders a <div> element and uses Backbone’s setElement function to tell a Backbone view that this is where it should live.

    This approach works great for inserting large isolated chunks of current stuff into an otherwise React app. Here’s a CodePen that proves this code works fine:

    See the Pen React + Backbone, step 1 by Swizec Teller (@swizec) on CodePen.

    That was easy. I did it all before my 3rd cup of tea! ?

    Now I’m stuck trying to make the data architecture inter-op. How do I build an overall unidirectional data flow architecture that works with these independent Backbone+Model views?

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    ... but #mobx smells a lot like Backbone-style state management and that's the whole reason we need a refactor.


    Hmmm… ?

    P.S.– I could seriously use some help with this refactor thing. If you're looking to get hired, shoot me an email.

    Did you enjoy this article?

    Published on September 20th, 2016 in backbone, backbonejs, Front End, react, reactjs, Technical

    Learned something new?
    Want to become an expert?

    Here's how it works 👇

    Leave your email and I'll send you thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

    Join Swizec's Newsletter

    And get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.

    "Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"

    ~ Ashish Kumar

    Join over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

    Have a burning question that you think I can answer? I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

    Ready to Stop copy pasting D3 examples and create data visualizations of your own?  Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

    Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

    Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️

    Created by Swizec with ❤️