Live data from Hacker News

Things every React.js beginner should know

camjackson.net

171–180 of 247 posts

Re: Things every React.js beginner should know

#171
post #76

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?

Is it really HTML or directive/component definition syntax This is not traditional HTML from the early days and because it is not it has a higher chance of reuse outside of just an internet webpage, and makes it easier to transfer across other view layers, canvas, native desktop/mobile views, etc

[deleted]

Re: Things every React.js beginner should know

#172
post #133

Some very good advice here but after reading through the list I had a familiar feeling. Functional, stateless, typed, Redux? Yep, that's Elm.

From what I can tell, the only reason to use React/Redux over Elm is to have a more popular resume. This is not a criticism, just an observation.

Re: Things every React.js beginner should know

#173

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?

1. It's not HTML, it's JSX, a vaguely XML-ish DSL that is compiled to JS. You can (and some people do) write the underlying JS code directly. But, obviously, writing a DSL that compiles to 'React.CreateElement.Div()' is the same (at least as far as seperation of concerns) as writing 'React.CreateEleemnt.Div()' directly.

2) Best practices focused on separation of concerns, and in particular, on avoiding embedding logic into your static HTML. The canonical example to avoid historically was to put JS directly into a links href attribute, but some have suggested Angular is guilty of something equivalent with its ng-* attributes.

3) Conversely, React advocates agree 100% on separation of concerns, but feel the "nothing that looks like HTML can be in the same file as something that looks like JS" injunction is actually an example of separation of technologies.

Re: Things every React.js beginner should know

#174
post #170
post #9

> 5. Use Redux.js Well, that is not really something every React.js beginner should know. Feels weird to say that a X beginner should learn framework Y since he is probably just interested in X... > 6. Always use propTypes Worth mentioning that this slows down your application since React needs to check all the props. Don't forget to set NODE_ENV=production when compiling your production script.

Neither this comment nor the article clearly spell this out: when you use the production version of React, much of the developer-assisting error checking is removed (not just propTypes[1], but many other error checks[2]), so you don't need to worry about the end-user performance impact of propTypes. As an example of how much this helps, one React-heavy page of mine dropped from 1500ms to 300ms by switching versions,…

OP is talking about compiling react in prod mode yourself, having pulled the source as an npm dependency, as opposed to pulling in the pre-built prod version with a script tag.

See the npm section right below the Individual Downloads section you've linked to in [2] - this is the recommended, and more common, way to use react.

Re: Things every React.js beginner should know

#175
So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or they hold off on adopting the tech until they are shown The Right Way™ by someone else.

The truth is, libraries and frameworks both end up being equally complex to work with, precisely because the problem of building large applications is inherently difficult.

It all comes down to personal preference:

Are you the type of person who is more likely to believe you can do something better than everyone else, or are you the type who is more likely to defer to those you believe to be better than you?

Are you decisive or do you agonize over the smallest choices?

Do you feel a compelling need to understand how everything works, or are you willing to implicitly trust other people's systems?

I find it amusing that people who gravitate toward smaller libraries like Backbone.js and React.js rail against frameworks like Ember or Angular for being overly complex, heavy, and "magical", and then proceed to cobble together a Rube-Goldberg-esque system of disparate dependencies to achieve the same goals. When React first started getting popular all you read about was how simple the API was and how it was Easy to Reason About™. Fast forward to today and you need to have working knowledge of WebPack, ES6, Redux, immutable.js, Babel, and a bevy of other dependencies to be aligned with the React ecosystem's ever-evolving best practices.

The exact same thing happened with Backbone.js and it will probably happen again with the next shiny new view-model library to ride the hype train.

It's important that I point out, however, that none of this is necessarily a bad thing. Smaller libraries like React.js and Backbone.js encourage a cavalcade of innovation from which awesome things like Redux are born. But let's not pretend that this doesn't result in a heckuva lot of churn for the average developer whose job is to simply get shit done.

Re: Things every React.js beginner should know

#176

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.

Re: Things every React.js beginner should know

#177
How about TypeScript/TSX? React's components and "views" are easy to type (and you get completion in your IDE) but I still have to find a convenient way to type an Immutable map where each key/value pair has a different type (the equivalent of a TypeScript object). Any idea?

Re: Things every React.js beginner should know

#178

How about TypeScript/TSX? React's components and "views" are easy to type (and you get completion in your IDE) but I still have to find a convenient way to type an Immutable map where each key/value pair has a different type (the equivalent of a TypeScript object). Any idea?

you can use the functional way of setState by passing a transaction function (state: State) => State . This allows for typed, immutable updates since the function gets passed a copy of the state.

If you need an object (say to use it in something like Redux), you have to write a wrapper like so: https://gist.github.com/ebi/d186c4297c84d562aeae

Re: Things every React.js beginner should know

#179

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you.

However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React.

Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux.

All other things are really not needed for most people, and if you do, you are facing problems so large, evaluation of libraries is a small fraction of the effort.

It's more the mindset of people "I'm missing something great" that drives them crazy and into framework fatigue. (OMG server-side rendering, falcor, relay, immutable.js arrgggh)

Usually, you are missing something you don't need, otherwise you would be looking for it actively.

Re: Things every React.js beginner should know

#180
post #64
post #24

Earlier quoted context omitted.

Putting HTML and JS in different files doesn't make them separated. They are still bound by logic. It's an imaginary separation with obscure dependencies. I very much prefer the React way of bundling things that in reality belong together.

It is quite possible to develop semantic, content focused HTML and then at a later point style and re-style with CSS. It is only through laziness and lack of understanding that people couple them together.

[deleted]
Post reply on HN