There are plenty of books, tutorials, and tools to help you start a brand new React project. But what if you already have a large application written in a legacy framework and you want to migrate to React? You can’t have your whole team drop everything and spend months rewriting your entire front end codebase. Jim will talk about challenges faced and solutions used by Conductor as they iteratively migrate to React from a large, complex, legacy Backbone app.
Scaling API-first – The story of a global engineering organization
Painless Migrations from Backbone to React/Redux
1. Painless Migration From
Backbone to React/Redux
Jim Sullivan
Engineering Manager @ Conductor
jim@conductor.com
Painless Migration From
Backbone to React/Redux
Jim Sullivan
Engineering Manager @ Conductor
jim@conductor.com
2. Painless Migration From
Backbone to React/Redux
Jim Sullivan
Engineering Manager @ Conductor
jim@conductor.com
any Legacy Framework
3. Painless Migration From
Backbone to React/Redux
Jim Sullivan
Engineering Manager @ Conductor
jim@conductor.com
any Legacy Framework
8. 8
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
JS @ CONDUCTOR: A BRIEF HISTORY
9. 9
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
JS @ CONDUCTOR: A BRIEF HISTORY
10. 10
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
Time to choose a framework!
JS @ CONDUCTOR: A BRIEF HISTORY
11. 11
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
Time to choose a framework!
JS @ CONDUCTOR: A BRIEF HISTORY
12. 12
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
Time to choose a framework!
JS @ CONDUCTOR: A BRIEF HISTORY
13. 13
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
Time to choose a framework!
Now we had
Object-oriented, non-global
JS @ CONDUCTOR: A BRIEF HISTORY
14. 14
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
Time to choose a framework!
Now we had
Object-oriented, non-global
Standard ways to do common actions
JS @ CONDUCTOR: A BRIEF HISTORY
15. 15
Growing JavaScript codebase since 2009
As of 2012
Large, complex JavaScript application
Homebrew/vanilla
Time to choose a framework!
Now we had
Object-oriented, non-global
Standard ways to do common actions
Architecture for layout and messaging
JS @ CONDUCTOR: A BRIEF HISTORY
17. 17
5 years!
As of 2017 – front end developers still feeling friction
JS @ CONDUCTOR: A BRIEF HISTORY
18. 18
5 years!
As of 2017 – front end developers still feeling friction
Hard to reason about data flow, messaging between components
Hard to reason about where state lived
Hard to reason about composing complex components and UIs
etc. etc.
JS @ CONDUCTOR: A BRIEF HISTORY
19. 19
Flow of data and communication between components is more coherent
State management is clearer
Handling of state changes is more predictable
Best practices and patterns around composing components and Uis
etc. etc.
WHY REACT/REDUX?
24. 24
Easy!
All frontend engineers
drop everything and stop building and
enhancing client-facing features
until we’ve completely replaced hundreds
of thousands of lines of JS code! 👍 👍
THE PLAN FOR MIGRATING TO REACT/REDUX
25. 25
Easy!
All frontend engineers
drop everything and stop building and
enhancing client-facing features
until we’ve completely replaced hundreds
of thousands of lines of JS code! 👍 👍
THE PLAN FOR MIGRATING TO REACT/REDUX
27. 27
THE (REAL) PLAN FOR MIGRATING TO REACT/REDUX
”…gradually create a new
system around the edges
of the old, letting it grow
slowly over several years
until the old system is
strangled.”
32. 32
Where it gets tricky
THE STRANGLER PATTERN ON THE FRONT END
33. 33
Where it gets tricky
1. “As a user, I see a fancy new version of some common component”
Rebuild it in React 👍
New component needs to live on Backbone screens 😱
THE STRANGLER PATTERN ON THE FRONT END
34. 34
Where it gets tricky
1. “As a user, I see a fancy new version of some common component”
Rebuild it in React 👍
New component needs to live on Backbone screens 😱
2. “As a user, I see a fancy new/updated screen containing some old
common components”
Build screen in React/Redux 👍
Old backbone components live on that screen 😱
THE STRANGLER PATTERN ON THE FRONT END
35. 35
Straightforward application of Strangler Pattern in UI:
Building new or updating old screens to 100% React/Redux
Having 100% React/Redux screens live in the same application as 100%
Backbone/Marionette screens
THE STRANGLER PATTERN ON THE FRONT END
36. 36
Straightforward application of Strangler Pattern in UI:
Building new or updating old screens to 100% React/Redux
Having 100% React/Redux screens live in the same application as 100%
Backbone/Marionette screens
Trickier application of Strangler Pattern in UI: hybrid screens
What we needed:
1. Ability to wrap React Components in Backbone Views
2. Ability to wrap Backbone views in React Components and have them
interact with Redux
THE STRANGLER PATTERN ON THE FRONT END
38. 38
We need a Backbone-style render method
React Component’s render method returns React elements intended
for the Virtual DOM
Backbone View’s render method directly modifies a DOM element
We need it to be easy so people use it!
WRAPPING REACT COMPONENTS IN BACKBONE VIEWS
44. 44
Three things to consider about wrapped Backbone views:
1. They will render HTML directly to the DOM, which is not consistent
with React Component.render
2. They may be stateful, and therefore are not disposable, i.e. must not
be re-instantiated
3. They may need to affect shared state, i.e. dispatch Redux actions
WRAPPING BACKBONE VIEWS IN REACT/REDUX
58. 58
~ 80% of front end development is happening in React/Redux right now
That number is growing quickly
WHERE ARE WE NOW? WHAT’S NEXT?
59. 59
~ 80% of front end development is happening in React/Redux right now
That number is growing quickly
How do we measure success? Shipping React/Redux code isn’t enough.
WHERE ARE WE NOW? WHAT’S NEXT?
60. 60
~ 80% of front end development is happening in React/Redux right now
That number is growing quickly
How do we measure success? Shipping React/Redux code isn’t enough.
Quality
WHERE ARE WE NOW? WHAT’S NEXT?
61. 61
~ 80% of front end development is happening in React/Redux right now
That number is growing quickly
How do we measure success? Shipping React/Redux code isn’t enough.
Quality
Velocity
WHERE ARE WE NOW? WHAT’S NEXT?
62. 62
~ 80% of front end development is happening in React/Redux right now
That number is growing quickly
How do we measure success? Shipping React/Redux code isn’t enough.
Quality
Velocity
Anecdotally: most engineers using R/R are saying they are faster, more
confident about quality, less frustrated
WHERE ARE WE NOW? WHAT’S NEXT?