What is a good pattern for entity editor components

[franck102]

Hi all, I have been using Vue 3 for a couple years, I read hundreds of posts & articles on the topic and I still cannot figure this out: what is the best pattern in Vue for an editor component that is responsible for editing an entity passed as a prop by its parent?

If trying to stick to the docs guidelines I don't want to modify the object passed by the parent, so I need to make a copy... and the key question is how to make sure that that copy is properly initialized in all situations (re-render, component instance being reused)... I have been bitten more than once by an editor displaying stale value from a different / previous entity.

The best I've come up with so far is something like this, but it doesn't feel right to have to use watch to handle that very common use case; I am aware of onUpdated, would that be better?

<script lang="ts" setup>
const props = defineProps<{
  item : ShoppingCartItem
}>()

const emit = defineEmits<{
  "update:item": [item: ShoppingCartItem]
}>();

const localItem = ref<ShoppingCartItem | null>(null);

watch(props, _props => {
   localItem.value = {..._props.item} // or whatever is needed to properly clone the item
}

</script>

Thanks!

[franck102]

I just re-read the docs to make sure I hadn't missed something obvious, and they have this to say ()::

The prop is used to pass in an initial value; the child component wants to use it as a local data property afterwards. In this case, it's best to define a local data property that uses the prop as its initial value:


const props = defineProps(['initialCounter'])

// counter only uses props.initialCounter as the initial value;
// it is disconnected from future prop updates.
const counter = ref(props.initialCounter)

Isn't this just a plain wrong solution? AFAIK the setup function will only be executed once so if/when the component is re-rendered or reused the local counter ref will not be updated?

Franck

[Yordan-Ramchev]

I don't think it's a plain wrong solution. <script setup> is triggered before the component mounts the DOM and assigns the initial prop value to the counter ref. It's not supposed to handle reactivity (it will be like a side effect). Imagine that you would like to create a function that will update the counter and at some point your parent updates the prop.

[franck102]

The issues lies in "triggered before the component mounts the DOM and assigns the initial prop value to the counter ref": it is unclear what that means, or when and how many times that happens.
The recommended pattern for a component should be agnostic of low-level details of DOM mounting, component instantiation etc which will be different if you use the component in a dialog, as the target of a router navigation, as the detail pane in a master/detail view... so IMHO the pattern in the docs is at the very least not very useful, and again IMHO misleading for beginners.

[Yordan-Ramchev]

IMO this is the correct case for a watcher.

1. watch or watchEffect - when the prop's value is dynamic, and you need to ensure that the local copy always reflects the current value of the prop
2. const counter = ref(props.initialCounter) - it is disconnected from future prop updates as mentioned in the documentation.
3. onUpdated - usually for DOM operations, when all the data is updated. I don't think this is DOM related.

This is good question and I would like to read some different opinions.

[franck102]

The prop being "dynamic" is one use case.

But the more common scenario, which IMHO the doc fails to cover appropriately, is the case when the editor is displayed, then hidden (user saves or cancels), then displayed again with different prop values. If my understanding is correct the counter or the entity will not be reinitialized without a watcher or some lifecycle hook.

Maybe watch(props, ...) is the way to go after all.

I saw the doc's mention of the ref being disconnected from future props changes... it is accurate, but IMHO misleading / confusing for users not experienced with components and their lifecycles.
In fact I have a hard time thinking of a useful use case for that pattern in a dynamic application where the component is displayed dynamically (routed to, or showed in a dialog) with changing props. And if it can't support that is it really a "component" ?

[Yordan-Ramchev]

Attaching a :key="someNewValueOnUserInteraction" and updating the value, you could force reinitializing. I think when the user hides/saves/etc, if you update the key it will retrigger new component render and the ref will take the latest value from the prop without a watcher.

https://vuejs.org/api/built-in-special-attributes.html#key