10 ms·
> 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
by TheCoelacanth 9y ago
> 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>
- pier25 9y agoAnd you think that's easier to read and write compared to any templating language of the last 15 years? Btw you missed :
- donpinkus 9y agoIt'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
- pier25 9y ago> Or when you want to loop through myList, but exclude a few particular items Easy, just create a computed property in Vue.
- yev 9y ago+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 9y agoYes, 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 9y agoThere'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.
- tigershark 9y agoI 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 9y agoAll of the "logic" inside render is _presentational_ logic. What would be a better place for that to go?
- infensus 9y agoBecause you don't really understand separation of concerns
- tigershark 9y agoI 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 9y agoHe 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 9y agoAh 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.
- ramses0 9y agoand marko => `<if(...)><li for(...)> ... </li></if><else><i>no results</i></else>`
- dwb 9y agoYes, by a long way.
- iammiles 9y agoI'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.
- luke3butler 9y agoBut 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.
- djur 9y agoReact does not force JSX use. JSX just compiles down to React.createElement.
- beefsack 9y agoI 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.
- djur 9y agoI 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).
- breeny592 9y agoNot 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).
- timmy-turner 9y agoRight, 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.
- hunterxg 9y agoFor 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.
- breeny592 9y agoDifferent 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.