Is it important that components always handle changes to props?

Generally when props change the component updates automatically, but there are some cases when there’s some dependant data that needs to be updated manually whenever the props change (using watchers, for example). Is it critical that devs always make sure that all of these changes are handled, even if the component at hand is used in such a way that it isn’t important at this point in time?

One common example is calculating something depending on prop values inside the mounted() or created() lifecycle hook. Because this calculation only happens in those hooks, if the values of the props change afterwards, the calculation isn’t going to occur again and the component could go into an invalid state.

The keyword here is - could. These components still work in the specific scenarios where they’re used. For example, a dev knows that the props aren’t going to be updated or he knows that the only way the props can be different is if the component gets re-created from scratch (having different props means that the user went back to some previous UI that didn’t have this component).

So is it important to prepare a component to always work in all possible scenarios handling all possible prop changes (future-proofing it), or is it fine to leave it as it is if you know it’s not going to run into those issues for the time being?

I think there is no generalization what is best… it’s about whats best for current scenario.

You can have component that need to take copy of the original data and allow user to do some manipulation…so when parent component updates the prop value you will probably not throw away an hour of users work …you will need to know who has bigger right / better version of data

But its more common to keep everything reactive. Maybe your component is displayed before the props are properly filled with data…because parent component does some lazy loading from API. And you offten will be able to write components driven by reactives…not by code in watchers and mounted…so there is description in template how the component looks when there are no data

It seems to me that’s a more general question about writing software and not limited to Vue or components. I don’t think there is a definitive answer, it comes down to experience and making a judgement about what the future is likely to bring.

Future proofing sounds great in theory but in practice:

  1. It takes extra effort.
  2. The extra code needs to be maintained.
  3. Code that isn’t used is likely to break without anyone noticing (tests may help but not always).
  4. The existence of the code gives the misleading impression that it is used… somewhere (comments may help but can also need maintaining).

Of course, there are also significant downsides to not future proofing. Documentation/comments can help to make the current contract explicit, though that might not be read prior to time being wasted.

Another factor is how obvious the problem is. If the component totally doesn’t work then it’s unlikely a future developer will miss that. If the problem is subtle then that’s more serious. If implementing a proper watch is a lot of effort it may be worth considering using a watch that throws an error, so at least the failure is obvious. Runtime assertions on the contract are a valid approach in the right circumstances. The experience levels of the developers also need to be considered when deciding what is ‘obvious’.

Even if the code isn’t future proofed it is worth considering whether the design makes adding the robustness later impossible. There’s a big difference between a component that doesn’t handle certain edge cases and a component that can’t handle them.