How to easily change the implementation?
Abstract away external dependency
Problem
Last week we’ve been changing support library from Intercom to HelpCrunch. We are using live chats in mobile and web applications. Since the beginning, we were abstracting away external dependencies. Thanks to that it was an extremely quick change. I’d like to share how to handle external dependencies, so you’re open to switching implementation.
Just to give you an overview, our technology stack is:
* React for web
* React Native for iOS & Android for mobile apps
* Node.js & GraphQL for backend
I’m going to use React in code samples, but that method is not limited to React in any way. We apply that to React, React Native & Node.js projects.
Simplest solution
Let’s start with the simplest solution. There is Help component, which on mount have to initialize external library. No matter which one you use, you’ll probably need some setup. We’re using context to get session info and bootstrap HelpCrunch.
Of course, initialization takes place only once. If there is only a single place, where we use dependency, it would handle that without any additional effort. Still, we’ll want to use some other methods from the library, like opening chat window or notifying about unread messages. We also want to open chat window in multiple scenarios:
* user clicks help button
* trial ends
* payment fails
* message from our customer success team arrives
Because of that external dependency will probably spread across whole codebase. If we stick to that solution, switching support library would require code changes in multiple places. Let’s move on to something better 🚀
Solution
Firstly, let’s simple extract initialization to separate function.
Now, we can move that to separate file — help.js and add other functions regarding support.
Anytime we use support, we’re going to import help module and use appropriate function. In case of initialization, we’ll end with Help component looking like this:
Why?
External dependency is used only in single file. Switching support provider is as simple as changing few lines of code. Switching from Intercom to HelpCrunch required change only in few function implementations in just one file. We didn’t have to touch every file that uses support functionality.
Of course, support functionality is limited to only handful of places. Changing provider, even without abstracting dependency away, would be straightforward anyway. However, if you consider something more complex like date handling, http calls or utils library, changing one implementation to the other would definitely require a lot of work.
Wrapping external dependencies with your module will definitely help to prepare your codebase for future changes. It’s also pretty simple to implement and the only problem is to stick to that solution. You need to remember that when you need support functionality, you should import your help module, rather than use external library directly.
