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.

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

4. 4

5. 5

6. 6
JS @ CONDUCTOR: A BRIEF HISTORY

7. 7
 Growing JavaScript codebase since 2009
JS @ CONDUCTOR: A BRIEF HISTORY

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

16. 16
 5 years!
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?

20. 20
THE PLAN FOR MIGRATING TO REACT/REDUX

21. 21
Easy!
THE PLAN FOR MIGRATING TO REACT/REDUX

22. 22
Easy!
All frontend engineers
THE PLAN FOR MIGRATING TO REACT/REDUX

23. 23
Easy!
All frontend engineers
drop everything and stop building and
enhancing client-facing features
THE PLAN FOR MIGRATING TO 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

26. 26
THE (REAL) 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.”

28. 28
THE STRANGLER PATTERN
A B C
👤

29. 29
THE STRANGLER PATTERN
A B C
👤
X

30. 30
THE STRANGLER PATTERN
A1 B C
👤
X

31. 31
THE STRANGLER PATTERN
A1 B1 C1
👤
X Y Z

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

37. 37
WARNING

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

39. 39
WRAPPING REACT COMPONENTS IN BACKBONE VIEWS
function createComponentBackboneWrapper(ComponentClass) {
const WrapperView = Backbone.View.extend({
// initialize(options)
// render()
// update(newProps)
});
return WrapperView;
};

40. 40
WRAPPING REACT COMPONENTS IN BACKBONE VIEWS
initialize(options) {
WrapperView.__super__.initialize.call(this, options);
const getPropsFromOptions = (options) => pick(options, (value, key) =>
contains(Object.keys(ComponentClass.propTypes, key));
this._componentProps = Object.freeze(getPropsFromOptions(options));
},

41. 41
WRAPPING REACT COMPONENTS IN BACKBONE VIEWS
initialize(options) {
WrapperView.__super__.initialize.call(this, options);
const getPropsFromOptions = (options) => pick(options, (value, key) =>
contains(Object.keys(ComponentClass.propTypes, key));
this._componentProps = Object.freeze(getPropsFromOptions(options));
},
render() {
ReactDOM.render(React.createElement(ComponentClass,
this._componentProps), this.el);
return this;
},

42. 42
WRAPPING REACT COMPONENTS IN BACKBONE VIEWS
update(newComponentProps) {
this._componentProps = Object.freeze(Object.assign(
{},
this._componentProps,
getPropsFromOptions(newComponentProps, propTypeKeys)
));
return this.render();
}

43. 43
import MyButton from = ‘./ReactButtonComponent’;
const WrapperView = createComponentBackboneWrapper(MyButton);
const view = new WrapperView({
text: 'Click me',
el: $('#the-button')
});
view.render();
view.update({ text: 'Don’t click me' });
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

45. 45
WRAPPING BACKBONE VIEWS: RENDERING

46. 46
WRAPPING BACKBONE VIEWS: RENDERING

47. 47
WRAPPING BACKBONE VIEWS: RENDERING

48. 48
class WrappedBackboneTextArea extends Component {
render() {
return ( <div ref={(ref) => { this._wrapperRef = ref; } } /> );
}
}
WRAPPING BACKBONE VIEWS: RENDERING

49. 49
class WrappedBackboneTextArea extends Component {
render() {
return ( <div ref={(ref) => { this._wrapperRef = ref; } } /> );
}
componentDidMount() {
this.wrappedTextArea = new MyBackboneTextArea ({
el: this._wrapperRef
});
this.wrappedTextArea.render();
}
}
WRAPPING BACKBONE VIEWS: RENDERING

50. 50
WRAPPING BACKBONE VIEWS: MAINTAINING STATE

51. 51
class WrappedBackboneTextArea extends Component {
shouldComponentUpdate() {
return false;
}
WRAPPING BACKBONE VIEWS: MAINTAINING STATE

52. 52
class WrappedBackboneTextArea extends Component {
shouldComponentUpdate() {
return false;
}
componentWillReceiveProps(nextProps) {
...
}
}
WRAPPING BACKBONE VIEWS: MAINTAINING STATE

53. 53
class WrappedBackboneTextArea extends Component {
shouldComponentUpdate() {
return false;
}
componentWillReceiveProps(nextProps) {
this.wrappedTextArea.model.set(nextProps);
}
}
WRAPPING BACKBONE VIEWS: MAINTAINING STATE

54. 54
WRAPPING BACKBONE VIEWS: AFFECTING SHARED STATE

55. 55
class WrappedBackboneTextArea extends Component {
static propTypes = {
onChange: PropTypes.func.isRequired
};
}
WRAPPING BACKBONE VIEWS: AFFECTING SHARED STATE

56. 56
class WrappedBackboneTextArea extends Component {
static propTypes = {
onChange: PropTypes.func.isRequired
};
componentDidMount() {
...
this.wrappedTextArea.model.on('change:text', () => {
this.props.onChange(this.wrappedTextArea.model.get(‘text’));
});
}
}
WRAPPING BACKBONE VIEWS: AFFECTING SHARED STATE

57. 57
WHERE ARE WE NOW? WHAT’S NEXT?

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?

63. 63
QUESTIONS?