Hacker News Reader

Comment by donpinkus | Hacker News Reader

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

View on HN

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.

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

Because you don't really understand separation of concerns

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.

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.

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.

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.)

> 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.

So let's recap.

* You don't know JSX

* You have no idea of the specific example posted in this thread that I'm speaking of

* You have no idea about WPF and what is a view model

But nonetheless you feel entitled to discuss about things in which you have zero knowledge. This is the JSX code posted in this thread:

<div> {listOfThings.map(thing => thing.isX ? <X thing={thing} /> <Y thing={thing} /> )} </div>

Instead of this monstrosity in XAML would be like this: <ItemsControl ItemsSource={Binding ListOfThings} />

But of course for you is better the JSX code. Luckily for me you will never have to review any of my pull requests, I seriously doubt that you can accept something that you don't understand.

I didn't have to go very far inside ItemsControl to see the example of the "presentation logic" you say doesn't exist. E.g.

https://msdn.microsoft.com/en-us/library/system.windows.cont...

What is that if not an horribly verbose switch case for modifying the representation of different elements passed to the ItemsControl?

I am not advocating that the JSX is particularly pretty or clever. I am objecting to your crazy notion that there should be no logic in the representation layer.

I asked you to please don't speak about things that you don't know. The page that you linked has nothing to do with presenting multiple items with different types. It is defining the visualisation of the control itself, defining the arrangement method for the contained items, defining the same visualisation for each item and finally it defines the container visualisation for each item. To replicate the JSX logic in the example discussed the code that I posted is all you need. It will bind the source of the ItemsControl to a list in the ViewModel that contains the different ViewModels that you need to display. WPF automatically will find the DataTemplates defined for those ViewModels and use that in the visualisation. No if, no switch, no map and nothing at all in the XAML file. Just:

I think you are comparing Apple with oranges here. React doesn't have a ViewModel notion that would binds data with Component. The binding is happening in the templates themselves so in the Component themselves and there is no in-between layer AFAIK.

If you are looking for exactly this feature you might be disappointed.

Vue.js and Angular have the ViewModel concept.

I have used those 2 frameworks in the past. Could you point me to the documentation about ViewModel in Vue.js I wasn't able to find anything relevant other than:

> Although not strictly associated with the MVVM pattern, Vue’s design was partly inspired by it. As a convention, we often use the variable vm (short for ViewModel) to refer to our Vue instance.

I am sure it wouldn't be very hard to develop such a layer within React if needed.

No, but he knows that templating languages have been wrestling with pretty much the same three or four issues since the beginning of HTML templates. It gets old.

It gets really old to see people try failed experiments over and over again, which pretty much is what you are suggesting.

Also, you got some display logic in your examples there, buddy. If you can't see it then no wonder this conversation is going in a circle.

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

Easy, just create a computed property in Vue.

+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).

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.

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.

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

Reply on news.ycombinator.com