In a larger Vue application you would use a data store (ie Vuex). The only thing that can mutate the data are "mutation" methods in the data store. It is your single source of truth.

If you aren't using a data store, your parent component would solely be responsible for mutating data. If the child component needed to alter it, it would raise an event that the parent would listen to and make whatever modifications necessary.

I'm having a lot of trouble truthfully understanding your "mental back-and-forth" issue and I'm wondering if it's an inexperience with Vue issue. Give it a try... I'm willing to bet you'll love it.

Maybe using "source of truth" was bad phrasing, the question is about rendering data not the data itself. I am convinced templates are a fundamentally broken technology. In React there's only one place things happen: in the JSX. This is not true for Vue -- you have at least two discrete objects (the template and the view) communicating back and forth.

Have you seen Vue's single file components?

It's a (single file), which would look something like (idk how to format code on h/n lol):

<template> <ul> <li v-for="message in messages">{{ message }}</li> </ul> </template>

<script> export default { data () { return { messages: ['hello', 'world'] } } } </script>

I realize this is a completely trivial example, but is this what you're getting at? Everything related to that component is in a single place. The template itself handles any UI specific logic: conditionally showing an element, looping, binding an event.

Any real logic is going to be handled from the component itself.

That said, Vue actually supports using a render function as opposed to using a template. You can even use JSX if you want (though I certainly wouldn't consider JSX a first class citizen in Vue).

But do you see the inter-dependencies between the script and the template? The template is assuming that it's provided a variable named messages and that it's an array of ready-to-display strings. And this information is stringly typed -- will your editor complain if you fail to define messages? Can I use Typescript to ensure that each message is what I expect? Sure, it's easy enough for simple examples but I've seen it fall apart quickly for large projects with multiple developers.

I'm not seeing the issue here.

This kind of system is extremely common on the backend---Python's Django and Ruby on Rails, to name a few frameworks follow the practice of templates being given data and simply acting upon it.

Since these are dynamically typed languages, there's no IDE typing support in the template.

There's just testing.

As someone who uses Django regularly, I can say there's a huge swatch of territory between "small examples" and "large projects".

That territory can easily cover teams of 19, and multimillion dollar projects.

Right, it's a common technology and it's always been a pain. With React everything is well-defined and typesafe (either through PropTypes, Typescript, or Flow) and the IDE support is fantastic.

That's my whole contention -- Vue is just a better iteration of the same old painful experience. React actually solves the problems I have.

the templates rendered. There is a singular state, because data flow is one directional. mutating properties is an anti-pattern in vue.

My guess is that they started looking at Vue before v2.

I don't know where you formed your impression of what Vue is like, but what you're describing is really not anything like it.

This is my impression of templates as a tool. I dislike Vue for the same reasons I dislike Angular and Marionette.

Ok... I mean, JSX is templates too; it's just a different syntax. Vue supports JSX if you prefer that syntax.

I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.

JSX is different though -- it's sugar around a 1:1 mapping to plain old JavaScript. There's no magic behind the scenes binding variables or interpreting stringly-typed code.

I wasn't aware you could use JSX with Vue. If you do, what benefits does Vue offer?

Vue simplifies a lot of the "data propagation" from what I've seen of React. I loved React's vdom and props, but just felt the syntax for props (e.g. `.setProp({name: val})` was excessive boiler plate. Vue simplifies that aspect with reactive props and data, its just more intuitive for me than React. One big improvement is the really nice system for `computed` and `watch` properties which reactively transform data. Your templates (jsx or the default html-directives, which I prefer) can rely on `computed` properties to transform from say an Dict to a list for say a list of `li` components. It gives a nice "raw input data -> reactive data transforms -> reactive html repr` flow.

Have you tried Vue? I had that impression too—that it's like Backbone/Marionette—but people have told me it's not. I don't think you mess with the DOM and I don't think you refer to elements except for the root, like in React.

Vue has one source of truth: the data stored in each component. You bind elements in the template to that data and they get automatically re-rendered when it changes, and you bind events in the template to methods (or just ad-hoc things like @click="toggleVar = !toggleVar" for a boolean) that update that data.

This includes child components, which trigger events that you bind in the parent component.

> @click="toggleVar = !toggleVar"

Oh boy. Another reason why I don't like templates -- you invariably end up with magical incantations like this. Working with JSX has given me an incredible distaste for templating languages.

Somewhat magical.

All bound expressions in Vue are javascript expressions. Names are typically bound on "this", which is the component instance. So the above expression is equivalent to

    this.toggleVar = !this.toggleVar.

Not entirely true -- I know there's at least special processing for filters: https://vuejs.org/v2/guide/syntax.html#Filters

"sources of truth" usually refers to data.

Having some designated separation of presentation and data is usually understood as a good thing.

I get that having them located in strongly separated locations increases workflow friction, but that isn't how Vue does things, and the rest of the problems you're talking about are present in any system where presentation and data have some kind of separation convention.

I'm also not convinced there where React is used to collapse the difference between the two it's actually solving problems rather than switching to a different set of problems, but then again I suppose every engineer has the right to pick which set of problems they prefer to wrestle with.