Function-based Component API (model usage) about rfcs HOT 6 CLOSED

I would personally use a computed setter to trigger the side effects (the $emit) and save the value locally in that countInternal because that way you can manipulate the computed property as a local value and forget about it

from rfcs.

First off, you have a name conflict between a prop and data returned by setup - both are called count`. Fixed here just to avoid confusion later.

export default {
  setup(props, { emit }) {
    const { count: countInternal, inc } = useCounter(props.count);
    watch(countInternal, (nextCount) => emit('update', nextCount));

    return { countInternal, inc };
  },
}

I think if you treat the count as an internal variable instead of exposing it to the component, the "One-way-data-flow" (data down, events up) works quite nicely:

function useCounter(initialCount) {
  const count = value(initialCount);
  function inc() {
    count.value++;
  };

  return { count, inc };
}

export default {
  setup(props, { emit }) {
    const { count: countInternal, inc } = useCounter(props.count);
    watch(countInternal, (nextCount) => emit('update', nextCount));

    return { inc };
  },
}

In the template, you would simply use the count from props - that's the original data that was passed down.

And to send an update up, you would have a method that emits the update.

And thinking about it this way makes the whole useCounter function a bit superfluous:

export default {
  setup(props, { emit }) {
    const inc = () => emit('update', props.count + 1)
    return { inc };
  },
}

But if we imagine that count would be some heavy logic that we wanted to be extracted, then it could be a pure function that we call in the inc method:

function count(value) {
  // there's no need to use any part of the new API here!
  // we could have extracted this logic out of a objects-based component's method
  // just as well. 
  return value++
}

export default {
  setup(props, { emit }) {
    const inc = () => emit('upate', count(props.count))
    return { inc };
  },
}

Or am I missing something?

from rfcs.

Okay, I think I miss something. So a question: Is this more about one of those situations where we

• have a "copy" of a prop's value as local state and
• then mutate this cached value,
• then sending the update to the parent?

I'm not entirely sure what the intended data flow or workflow is...

from rfcs.

Or am I missing something?

idk, really. i mean the example is too simple to argue against your alternatives. but lets imagine a useX that needs multiple values from props (that are maybe even passed to other useY) and probably multiple values to emit.

i think the first question should be: do we should use watch to emit value changes? or is this more like a very corner use case?

from rfcs.

let's imagine a useX that needs multiple values from props (that are maybe even passed to other useY) and probably multiple values to emit.

I'm sorry but this is so unspecific that I can't really come up with a pseudo example to address it.

I can relate to the "gut feeling" you seem to have about an unclarity here, though.

Maybe we can come up with something more concrete written in the current API as a starting point?

from rfcs.

I'll close this as it seems to go nowhere

from rfcs.