Live data from Hacker News

Things every React.js beginner should know

camjackson.net

51–60 of 247 posts

Re: Things every React.js beginner should know

#51
post #15

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

Take a look at the talk where the concepts behind React are introduced: https://www.youtube.com/watch?v=x7cQ3mrcKaY It turns out there is no good reason to separate code and templates, because they are intrisically linked; one cannot work without the other. The separation should rather happen on units that are really independent, such as 2 separate pages of your application.

Yep, it was an old rule for an old time when back-end functionality, UI functionality and presentation could all get jammed into one *SP or PHP page. While the times changed the common wisdom remained. There is no reason for a component that's sole purpose is to be a component should not be self contained. It is a black box to the consumers.

Re: Things every React.js beginner should know

#52

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

The early web days were spend developing basic web pages without any complex tools.

These days everyone seems to think they need an application style site, and whilst some sites really do benefit from this approach, others don't.

The trinity of web standards (html/js/css) are still valid for informational, mostly static web pages, but are impractical for developing applications.

The discussion of what is a web application is a tricky one to put a finger on, with a lot of grey area. I think of a classic web page being the about us page of a website, while an application is something like photoshop. In between you have things like twitter, or gmail, amazon, facebook etc.

Re: Things every React.js beginner should know

#53

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

Nothing prevents you from not putting HTML inside JavaScript when using React. Personally I've found that this JSX approach doesn't integrate with certain editors very well, so I just use raw React.createElement calls. Assign it to a short variable and it really isn't bad at all. I even tried a s-exp syntactical transformer, and it works even better. HTML is basically just s-exp with an ugly syntax, so it feels even more natural doing that.

Re: Things every React.js beginner should know

#54

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

When I first began delving into reactive client interface frameworks. This was one of my biggest gripes. It looks, and reads like a giant confusing mess. I finally came across http://vuejs.org/ and I haven't looked back. Simple binding syntax to html elements, and powerful enough for most projects without being heavyweight.

I mean it doesn't get any more straightforward than this.

{{ message }}

new Vue({ el: '#app', data: { message: 'Hello Vue.js!' } })

Re: Things every React.js beginner should know

#55
post #23

Earlier quoted context omitted.

This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don't keep track of the reasons why a law came into use in the first place, we might miss the moment where it might not apply anymore (we wont even know, really) While I'm not entirely…

Actually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are intermixed in a single file. React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.

In all fairness this is ancient history on the PHP world.

Re: Things every React.js beginner should know

#56

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

Isn't that because it's really JSX? https://facebook.github.io/react/docs/jsx-in-depth.html [NB Not that I know, just checking my own understanding].

I hadn't heard about JSX before so I went to your link to check it out. This is just one of the most off-putting introductory statements I've ever read:

    JSX is a JavaScript syntax extension that looks similar to XML.
Don't we all hate XML? How can you possibly even go on reading about this technology further if it's introduced like that.

Re: Things every React.js beginner should know

#57
post #18

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

A lot of recent trends feel like going backwards to grumpy-me as well. Microservices being preached basically the same way SOA was (and falling on every single pitfall again), languages where copypasta and mutable state are "the idiomatic way", HTML inside js code. Granted, not all recent developments are bad, of course - eg compiled & typed languages being back in "fashion" is a good development imho. It just feels…

[deleted]

Re: Things every React.js beginner should know

#58
post #55

Earlier quoted context omitted.

Actually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are intermixed in a single file. React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.

In all fairness this is ancient history on the PHP world.

That's the point that pkrumins/andreyvit are making, code where logic and presentation are mixed turn into a nightmare to maintain. And the practice is now ancient history.

Apart from here it is again...

Re: Things every React.js beginner should know

#59

#3 Write functional components I'd say "Write functional components where it makes sense". For simple components that is a reasonable advise, however in cases when you need such methods as `componentDidUpdate` or generally any lifecycle methods - that won't do and you have to use classes.

Not a React guy, but why couldn't the component that updated broadcast that it did so? Or is that componentDidUpdate method a callback to the message I'm describing?

Re: Things every React.js beginner should know

#60
post #23

Earlier quoted context omitted.

This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don't keep track of the reasons why a law came into use in the first place, we might miss the moment where it might not apply anymore (we wont even know, really) While I'm not entirely…

The big reason I remember from my PHP days (late 90s early 2000s) is that you want to separate design from development. Graphic designers were expected to know HTML/CSS while developers focus on PHP.

That's never really been true. Graphic designers rarely knew HTML/CSS in the old days.
Post reply on HN