Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: