Hacker News Reader

Comment by TheCoelacanth | Hacker News Reader

> It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading.

I don't get this complaint at all. Between map and ternary expressions, you can get both loops and conditionals in your markup, e.g.

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

View on HN

Not to mention that if a section of markup gets too big, you can break that down to it's own method that returns tiny snippets so you can have really simple methods that end up creating the more complex end result i.e.

_renderXOrY = (thing) => { return thing.isX ? <X thing={thing} /> : <Y thing={thing} /> }

//inside the render method <div> {listOfThings.map(thing => this._renderXOrY(thing))} </div>

I personally prefer this because when creating the top level of a component, I largely don't care about the individual elements of a list, but rather am structuring how that list will be contained etc.

And let's not discount then the value that JSX brings of being able to easily unit test that your conditional logic renders the correct output easily (Jest + Enzyme = easiest tests I've ever had to write, bar simple functional checks).

Right, being able to compose, test, structure and develop my HTML in the same way I'm doing it with my application code is for me the main Reason for never wanting to go back to anything that's based on classic string-like templating. The latter always felt as clunky as programming without a proper function abstraction.

For me it's quite the opposite. I find that so confusing when you look at html in JavaScript and don't know right away what the result will be. It's like were back in 2002 doing PHP.

Different strokes for different folks - my thought to that is pretty much that I don't really care what the result will be on the grand scheme, but more specifically isolated nodes and how they will interact with my model/data etc.

Having the ability to see exactly what's in scope right next to the markup to me is invaluable - one of my biggest dislikes in templating languages is swapping between files that define the data in the scope and the template to use said data.

I'm with you on this. JSX is quite a bit easier for me to reason about than the Angular-like expressions of Vue. But I am glad that there are viable alternatives available for those who don't feel the same way.

But you can use JSX with Vue if that's what you prefer. Vue passes everything down to render functions in the end anyways.

React forces JSX use, so a lot of times the battle between Vue vs React seems to be Vue Templates vs JSX which never makes sense to me.

React does not force JSX use. JSX just compiles down to React.createElement.

I feel React.createElement is so unergonomic it's not really an option to use directly. A lot of React supporters mention it when people criticise JSX, but I don't think it's a pragmatic alternative.

I know people who use React without JSX and it reads fine, as long as you assign React.createElement to a shorter alias. I like that you don't have the visual noise of closing elements. I think it's mostly a matter of taste (and how much you care about your HTML-generating code resembling HTML).

And you think that's easier to read and write compared to any templating language of the last 15 years?

Btw you missed :

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

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

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.

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

Yes, by a long way.

Reply on news.ycombinator.com