[donpinkus]

It's slightly less easy to read than <li ng-each={myList}>...</li>

But it means you don't have to learn a library's HTML API.

Or when you want to loop through myList, but exclude a few particular items... you know how to write that in JS, but have no idea what to do in the mark up language. You could create a filteredList, but it's often not ideal

[tigershark]

I cannot really understand how today mixing logic and presentation in JSX is considered a good thing. The first principle when writing complex systems should be to completely separate the logic from the presentation layer. Nowadays people seem happy with intermingled monstrosities like the one shown in the JSX code upstream.

[HeyImAlex]

All of the "logic" inside render is _presentational_ logic. What would be a better place for that to go?

[infensus]

Because you don't really understand separation of concerns

[tigershark]

I think I understand it quite well having worked for more than a decade on complex systems. I can't say the same for you if you think that putting some logic in the presentation layer like the example above is a good thing. I would always transform my domain in the model object while the presentation layer should only present the transformed model. Using a map function directly in JSX is a sure recipe for disaster in a complex system. But I seriously doubt that you can understand this looking at your answer.

[batiste]

He is right taught. You are allowed to have all the logic you want in your presentation layer. As long as it is presentation logic this perfect. If it is "Business logic" then this is wrong. Have you realised than having a if statement is already "logic"? Template system that don't have if statement are absolute trash IMHO.

[tigershark]

Ah ok. So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong. I don't know Vue.js, but in WPF I would have simply bound an ItemsConttol to the list of models. Stop. Finished. No presentation logic at all in the XAML file. WPF will automatically bind the correct DataTemplate to the specific ViewModel contained in the list. I would have never ever approved a pull request in which someone implemented that using a monstrosity similar to the one shown in this thread. The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model. Reading this thread, apparently in React is encouraged to do whatever sh@t you want directly in the JSX file rather than delegating it to where it belongs. Heck, you are even excited that JSX is Turing complete, as if it was a good thing. I will continue happily to write my code respecting the separation of concerns, leaving all the logic out of the XAML or HTML. You are free to continue to put everything in the JSX if you like it, but don't expect me to stay silent when you mislead many people in thinking that writing logic in JSX is the right way to go.

[batiste]

> So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong

I don't really know JSX much and without a specific example this is pointless to discuss. But basically JSX is syntactic sugar over javascript. A ternary is just a "if" condition so I don't see where is the issue here. Are you really using a template language devoid of conditionals? Even mustache the "logic-less" template has a form of it.

> The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model

The role of the model is and has always been to handle /business/ logic not presentational logic. If you put your dirty presentational logic inside my models I can tell you I will /never never/ accept your pull request.

[ghusbands]

It's useful to separate mantra and intent, here. Yes, separation of concerns is a useful thing, but if you just take it to mean that no logic should ever be involved in your templates, you're taking it too far and unnecessarily complicating things. If a section of the page is scrollable or expandable, the scroll and expansion state (and event-handlers) clearly live in the presentation layer and don't belong in any of the data model. (They aren't the only examples, but they are ones that most people accept.)

[pier25]

> Or when you want to loop through myList, but exclude a few particular items

Easy, just create a computed property in Vue.

[yev]

+1, Also as a side effect you will get a cleaner declaration of the filtered list (rather than making it a part of the rendering process, lol).

[ghusbands]

Yes, that's easy, but adding something to your model just because your view wants it rather seems like the cart driving the horse. If your view needs something that your model otherwise has no use for, then it does not belong in the model.

[chii]

There's no real clear cut line where you can say that a model had no 'use for' a certain field.

If your point of view is that a model is meant for more than just doing the view, then yes, adding view only fields may pollute it for others (e.g., analytics).

But if your model is meant to drive the view of the app, then the story is very different. And some times you can't even tell if the model is just there to drive the view our not, since requirements change often.

[ramses0]

and marko => `<if(...)><li for(...)> ... </li></if><else><i>no results</i></else>`