next version of post

sdras · sdras · commit f889b81acd25 · 2020-10-31T22:15:46.000-06:00
diff --git a/src/cookbook/gradual-compositionapi-migration.md b/src/cookbook/gradual-compositionapi-migration.md
@@ -1,6 +1,6 @@
 # Gradual Composition API Migration
 
-The Composition API is an advanced feature introduced in Vue 3. It is purely additive, the Options API is not legacy, however you may find that the Composition API can be a useful feature for more flexible large-scale architectures. So how would we go about introducing it in a larger system, gradually? The following is merely a recommendation, there are many ways of going about this.
+The [Composition API](/guide/composition-api-introduction.html) is an advanced feature introduced in Vue 3. It is purely additive, and the Options API is not legacy. You may find, however, that the Composition API can be a useful feature for more flexible large-scale architectures. So how would we go about introducing it in a larger system, gradually? What follows is merely a recommendation, there are many potential ways forward.
 
 Due to the flexibility of the Composition API, you may need to be more explicit about organization so that future maintainers can quickly understand intended purpose of pieces of the application.
 
@@ -122,21 +122,21 @@ And we can refactor our component as follows:
      sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
    ></iframe>
 
-Note that the template stays the same, but we've extracted the logic to use in our script section differently. If, from here, we wanted to use `isShowing` in the Options API, we could access it with `this.isShowing`, just as we normally do with a data property, and similarly, we can access `this.toggleShow` like we would a method.
+Note that the template stays the same, but we've extracted the logic to use in our script section differently. If, from here, we wanted to use `isShowing` in the Options API, we could access it with `this.isShowing` now, just as we normally do with a data property, and similarly, we can access `this.toggleShow` like we would a method.
 
 You may notice we used `reactive` here instead of `refs`. This is intentional- if you're refactoring a codebase, potentially full of many many values, `reactive` translates faster and more directly as the API is closer to Options, you're still using that same object notation.
 
 ## In Place of Vuex
 
-It is possible to use the Composition API in place of Vuex, and save yourself a dependency. That said, it's not exactly necessary, either. And there are some tradeoffs.
+It is possible to use the Composition API in place of Vuex, and save yourself a dependency. That said, it's not exactly necessary, and like many approaches, there are tradeoffs.
 
-If you're using Vuex, it's very clear exactly what centralized state is being used across the application. Composition API is very flexible, but you may lose that implicit declaration in communication to other fellow maintainers. Our suggestion that if you do use it as a centralized state management store, that you place it in a `store` folder, or something similarly named, so that responsibilities are clear.
+If you're using Vuex, it's very clear exactly what centralized state is being used across the application. Composition API is very flexible, but you may lose that implicit declaration in communication to fellow maintainers. Our suggestion that if you do use it as a centralized state management store, that you place it in a `store` folder, or something similarly named, so that responsibilities are clear.
 
 ## Components
 
-It is possible at this point to start to move your components to the Composition API, however, for larger code bases, you may not see immediate need or good reason to, as the Options API still works nicely.
+It is possible at this point to start to move your components to the Composition API, however, for larger code bases, you may not see immediate need or good reason to, as the Options API works nicely.
 
-Our suggestion is to use this opportunity to instead refactor any larger components that have too much responsibility on their own.
+Our suggestion is to use this opportunity to think through the architecture and refactor any larger components that have too much responsibility on their own.
 
 For instance, if you have a component has the following methods:
 
@@ -145,11 +145,13 @@ For instance, if you have a component has the following methods:
 - one that uses the input to call out to an API
 - one that does something with that API response
 
-You may find that the one component has a lot of responsibility, and it may make sense to break this apart more.
+You may find that you can potentially create a reusable component for the API call, as on a large application there's a fairly high chance you will need to make another.
+
+[VueUse](https://vueuse.js.org/) is a great resource to explore that covers many of these encapsulated use cases.
 
 ## Alternative Patterns
 
-Not everything needs to be refactored, though. Use judgement to guide you and not hype. The Options API can support a lot of use cases, and it's absolutely fine to keep your components in the Options API, and move reusable logic and/or state management to Composition API, depending on your needs.
+Not everything needs to be refactored, though. Use judgement to guide you and not hype. The Options API can support quite a lot of use cases, and it's absolutely fine to keep your components in the Options API, and move reusable logic and/or state management to Composition API, depending on your needs.
 
 Remember: the strength of the Composition API is in:
 
