Best practice for changing component to a new version

(yuio) #1

Hello. I want to upgrade my component. But it already used in many places in my app and changing will cause many side effects. What is properly way to do that? I’m going to create a new one with ‘New’ addition. But I think it’s not correct.

(jalooc) #2

Snapshot tests may be some kind of help here - if you take snapshots of some parts of your app before the change, and compare them to the snapshots made after the change, you’ll have a clear view what will have changed. It won’t help in the transition itself, but it’ll help you clean up after it.

As to the transition - have you considered changing the implementation of the old component, instead of creating a new one from scratch? It can go smoothly if you keep the component’s interface backwards compatible. Of course, it’s not possible in case of more thorough transitions.

(Per Jansson) #3

I have been using codemods with jscodeshift to do this kind of changes. I gives you a chance to update all the users of the component, to use the new version, in one go. Codemods is a kind of programmatic refactor where you write a transform script to change your code from using the old component to the new component.

Depending on how big difference in the api, and what type of change it is, of the component it will be the task of creating the transform script will be either easy or hard.

(yuio) #4

I had two options for creating new component based on old:

  1. with clean code but without backward compatible
  2. with extra code for backward compatible
    I thought there is name convention for updated components.
    Example: I updated component and named it using ‘New’ addition or version or whatever. Old component could get ‘Legacy’ addition. In future I’ll use updated component, but old will remain and app will work ok. Old component will gradually remove from app when I’ll get extra time for refactoring.