Any real issue with using watch in sibling component?

[andrew-vdb]

I just refactored one component into two components
Because they share state, then I create shared state in store.js as in documentation
Now the event between those two component need to be re-wired

I tried many things but it seems using watch is the simplest future proof solution (say in future i need to split or merge component again)
compared to using

• event emit, v-on
• tiny emitter (event bus), don't want to put any third party if not really necessary

is watch internally polling change? (there is one stackoverlow that say it like that) or simply callback (which means just event handler onChange or something like that)

is there any real issu? or just maintainability?

[andrew-vdb]

In the end, i create simple event callback in store.js and simply use that

[s3xysteak]

esm

• /views
  • my-store.js
  • foo.vue
  • bar.vue

// my-store.js

export const val = ref(1)

// foo.vue
import { val } from './my-store'

setTimeout(() => {
  val.value = 2
}, 3000)

// bar.vue
import { val } from './my-store'

watchEffect(() => {
  console.log(val.value)
  // 1
  // 2 - after 3s
})

Or shared statement in the father component

• father.vue
• Foo.vue
• Bar.vue

// father.vue
<script setup>
import Foo from './Foo.vue'
import Bar from './Bar.vue'

const state = ref(1)
</script>

<template>
  <Foo v-model:value="state" />
  <Bar v-model:value="state" />
</template>

// Foo.vue
const state = defineModel('value')

// ...

Others are same as the example above.

[andrew-vdb]

I use watch instead watchEffect... then use callback