Live data from Hacker News

Things every React.js beginner should know

camjackson.net

101–110 of 247 posts

Re: Things every React.js beginner should know

#101
Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it.

What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?

Thanks!

Re: Things every React.js beginner should know

#102
post #30

Earlier quoted context omitted.

The old advice was wrong anyway. First, in practice what everybody turned up doing was the inverse (add programming logic inside their HTML). So you still had mixed HTML and JS, but in a way worse way: with ad-hoc and incompatible pseudo-languages (e.g. Angular's ng-repeat etc, Knockout's template instructions, etc), spiced with "JS inside HTML attributes", with no syntax checking (a typo could blow your code in runt…

> After all in every native UI framework you have instructions to draw the widget IN your code -- not as some external additional technology. A widget's C/C++/Obj-C/Swift/Java/C# etc code encapsulates everything about creating it and showing it. With the notable exception of Windows. XAML strictly enforces code and markup separation. It makes the View layer more toolable and easier to edit by designers who usually do…

Thats not really true - you can use some pretty convoluted converters directly into the XAML and you can have those trigger arbitrary functions in your program through one-way binding.

Re: Things every React.js beginner should know

#103

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?

This is a debate that has been going on since I started in the late 90ies. You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates. Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language. .. so they invent template languages... ... that then expand to be turing-complete and basically offer…

It is the people who LIKE putting logic in templates who want Turing-complete template languages with all the features of the host language. If you don't do much or any logic in templates, you have no reason to want that.

It sounds to me like you are arguing that because people will put logic in templates, and this leads to ugly template languages, we should just program in ugly template languages rather than doing any separation of logic from templates.

Re: Things every React.js beginner should know

#104

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?

This is a debate that has been going on since I started in the late 90ies. You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates. Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language. .. so they invent template languages... ... that then expand to be turing-complete and basically offer…

Definitely agree with "the best language for that is the one you're using everywhere else"

Where I work right now, we use the newer versions of ASP.NET that come bundled with the Razor templating engine, which uses .cshtml files. You can write C# inside the files much the same way you can write JavaScript in a JSX file, it makes creating forms and such a breeze.

Big bonus is that moving from writing server-side logic to client-side logic doesn't require much of a context switch, and you can use the same objects to represent your data on both sides. If I spend all day moving between half a dozen different languages that get compiled by a dozen different tools, it can get a little exhausting.

Re: Things every React.js beginner should know

#105

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!

If it works for you stick with it. I started with webpack for the same reason-- I wanted to use ES6 syntax, and a coworker had some boilerplate that did most of the work for me.

Re: Things every React.js beginner should know

#106
post #78

What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?

In the cases where react makes sense - where the users change data together or where new data is often enough generated on the server, yes. Try to make Trello work as well as it does today without javascript - ain't happening, you would be reloading every few seconds in case somebody else has made some changes.

On e.g a newssite react doesn't make much sense though (except, possibly on the backend).

Re: Things every React.js beginner should know

#107

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!

I found code splitting feature useful. It's insanely easy to lazy load partial script.

https://webpack.github.io/docs/code-splitting.html

Re: Things every React.js beginner should know

#108

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?

This is a common misconception. You're not actually writing HTML. You're writing `React.createElement` calls in an HTML-like syntax. This is just to make it very easy and fairly pleasurable to write your templates out.

Re: Things every React.js beginner should know

#109

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!

I think Webpack has the monolith advantage here. It allows you to add things that would otherwise be immensely complex with ease because it can do a lot. You can have it handle bundle splitting and async loading of modules, image optimising and hashing, CSS/SASS/... processing, ...

Since we started using Webpack where I work we've stopped using all other build tools. There's very little Webpack can't do, and the main advantage is that there's no need to hook things up to eachother since it's all part of the same system.

Re: Things every React.js beginner should know

#110

#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?

Depends on what kind of component just updated. If it's a low level text field, it probably shouldn't broadcast the change to anywhere else in the program. Instead it would invoke it's 'onChange' callback. This way, there are no extra dependencies for making the text field component work. The parent component always provides the onChange callback and takes action accordingly.

However, if the component that just updated is high level, like an entire page or something, then it's reasonable to assume it's a one-off controller component and you should feel free to broadcast messages and couple the component with other parts of the program.

https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

Post reply on HN