Hacker News Reader

Comment by greyskull | Hacker News Reader

There's something that irks me about incorporating logic into templates. UI development is hard enough without having to bounce between js and templates to figure out how a component is actually going to behave. I haven't used Vue or React, so this is all just my gut speaking, but at least with React all the logic is there in front of you.

In my mind, if there's a loop or a conditional or whatever piece of logic that decides what will actually show up, that should happen where the underlying data/models is actually built, and whatever acts as the view just spits it into place.

I'm still a scrub when it comes to web and UI development, so I may be speaking out of inexperience.

Am I missing something?

View on HN

I just don't like the bidirectional data binding that vue seems to bring with it... I've had enough experience with this in Angular at this point to know that it's painful... then the easiest way around those issues is to use classes, and computed property getters and setters. In the end, it's just painful.

React is much clearer here, but there is more of a cognitive load in getting used to it, there's less magic at the surface. Even combining with something like Redux, or even MobX has another layer of understanding... routing and server-side rendering more still.. but they are layers you learn and add, not everything in one neat package.

I'm also not a fan of the custom DSLs that tend to come with templating engines.

> and computed property getters and setters

It's the exact way how it's implemented in Vue, with old fashion getters/setters and some "magic" for already defined object fields, see for details https://vuejs.org/guide/reactivity.html Vue has no digest cycle (no dirty checking), so you there is no Angular's performance issues.

> I just don't like the bidirectional data binding that vue seems to bring with it...

Vue 2 ditches it entirely, in favor of Vuex, which is inspired by Redux in part. http://vuex.vuejs.org/en/intro.html

Vue 2.0 moves away from two-way binding.

Vue single file components behave very similar to React.

The main reason I chose React over Vue is that I found React components were much easier to compose than Vue. This mainly came from them using handlebars, a very suitable library for when Vue was first implemented.

From what I understand, soon you'll be able to use JSX in Vue components - which would negate this advantage. I would certainly consider Vue again for my next project.

The only logic in my views are related to the view. Things like rounding numbers, filtering and sorting lists, looping over a model to render the components. I think these parts have no place in the business logic and the view layer is the appropriate place for them.

It's already possible to use JSX with Vue components, since the 2.0 release.

> Am I missing something?

Yes I think. If I follow your approach without thinking I would end up with quite a few almost similar templates where I now have one with an simple switch depending on how it is used.

I think it depends on how broadly the template is defined. If you can reasonably limit it to the portion of the UI that is impacted by the data then it isn't so bad to have logic in the template. If the model is built on the server-side, this approach ensures you don't have markup polluting your server-side code and making it less manageable in the long term.

If you're thinking about the difference between data and presentation, then you can usually limit the damage caused by "logic in templates"

Though you might want to precompute some values in your data to make the presentation code cleaner, of course.

It's also important to make things as "component"-y as possible. This is an instinct we don't have when doing HTML stuff by default, because the language itself isn't really used like that in "normal" development.

So you have your data, and then your template ends up being pretty minimal in logic, leaving just some core bits that are purely presentational.

For example:

    <p> Your Transactions </p>

    <div ng-if="userData.hasTransactions">
      <TransactionList data="userData.transactions">
    </div>
    <div ng-if="userData.hasTransactions">
      <p> Please configure your transactions <a>here</a></p>
    </div>

Yes, v-for is not a for loop in the sense of looping and building up data. It's a pure repeater presenting already existing arrays of data.

Then you get into the gray zone with filters and v-if but somewhere you have to do switching and for many things, having the code where it is actually used makes most sense.

The data should decide what will show up and the template should decide how. Eg: if data.ok img.url=ok.png else img.url=error.png

The if there is totally okay to have in your template because it's deciding how the data should be presented. The data model should not need to know which images are being used, or even care that you are using images at all.

Reply on news.ycombinator.com