Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things every React.js beginner should know

camjackson.net

Post reply on HN
Print view View original

91–100 of 247 posts

Re: Things every React.js beginner should know

#91

Post by aikah »

matt4077 wrote: post #79
pkrumins wrote: post #10

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…

> ... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning.

then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty )

so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists already, but since current developers grew up with C like languages, it is not that popular.

IMHO the best compromise is direct support for XML syntax inside languages (which Javascript had at some point with E4X) because I don't think anyone will be able to make developers use LISP like languages on a wide scale. JSX, with some modifications and standardisation could also be a solution.

Re: Things every React.js beginner should know

#92

Post by dminor »

matt4077 wrote: post #79
pkrumins wrote: post #10

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's not true though that you need logic in your templates - see https://github.com/cgrand/enlive for a counterexample.

Re: Things every React.js beginner should know

#93

Post by swah »

lukesan wrote: post #89
andrewingram wrote: post #80

Earlier quoted context omitted.

This isn't strictly true. Though the workflow isn't ideal yet, it's perfectly possible to build a React project which is initially rendered on the server and then progressively enhanced. I've done it before, as have others. In fact, my single biggest criteria for any tech I add to my stack is that it doesn't get in the way of server-side rendering (the second biggest criteria is that it doesn't add significant weight…

Sounds great. Do you know any good resources for building a react application by progressive enhancement?

Google "server side React rendering".

Re: Things every React.js beginner should know

#94

Post by stickperson »

mythz wrote: post #43

# 3. Write functional components Functional Components don't get Redux's connect performance optimizations which is a good reason to avoid them: https://github.com/rackt/redux/issues/1176#issuecomment-1670...

I think Dan is making a different point. He's saying functional components are just like regular components in terms of speed. The author of this article is saying use functional components so it's clearer when a component needs to be split up.

Re: Things every React.js beginner should know

#95

Post by tomjen3 »

pkrumins wrote: post #10

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?

Only in the appropriately named render method, which will use code to choose what to render and not to do anything else. How else would you satisfy the requirement to display a list of items and a special item if the list is empty?

The danger you run into is PHP nightmares where the programmer has e.g code that accesses and fetches items from a database in the middle of the view.

Re: Things every React.js beginner should know

#96

Post by toolz »

matt4077 wrote: post #79
pkrumins wrote: post #10

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…

Pakyow also uses logicless templates. It achieves this by having processors in ruby that you can bind to scopes/attributes.

Now I have everything I need to process this html with my logic to turn it into

Frank Bob

https://pakyow.org/

edit: I wish downvotes required commenting on why you're downvoting.

Re: Things every React.js beginner should know

#97

Post by _pmf_ »

Aleman360 wrote: post #37
coldtea wrote: 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…

I agree that XAML has the most mature concept, but it cheats by introducing the MVVM pattern, which performs some data mangling that would otherwise be part of the view. Not doing this, you'll end up with custom converters etc.

MVVM is nice regarding testability, but I find it to be overkill for most applications.

Re: Things every React.js beginner should know

#98

Post by todd3834 »

Great article! As we have been on-boarding developers with React, we noticed that all of the boilerplate needed to get Babel, Webpack, Redux, and a testing environment (we use Mocha, Karma, and Chai) was simply too much for most people to handle while beginning something new. There are lots of boilerplate projects but telling someone new to fork a project on GitHub and start building an app from there was raising some eyebrows as well.

That's not all, there are really amazing developer tools available for React development like the redux dev tools, and hot module replacement to name a couple. These tools are extremely helpful to beginners but a beginner is not going to enjoy the extra work of setting that up as well.

Imagine if you were going to build an app with Rails and the instructions were to follow a tutorial that had you manually hook up active record, create your bootstrap files by hand, write your own code to rebuild the server ever time code changed… or even forking a boilerplate Rails project and going from there. I don't believe Rails would have become what it is today without the Rails CLI.

What happens when the boilerplate changes? What if you find a XSS vulnerability in the boilerplate project that you used in your last 10 projects. Rails developers have identified and quickly patched several security vulnerabilities over the years. It's usually as easy as updating a gem file to patch your app. With the boilerplate approach, you would have to manually update all of your apps or try to merge the update from the project your forked. That isn't going to be fun at all.

Finally, one of the coolest things you can do with React is server side rendering to build universal apps. At this point, even if you know exactly what you are doing, setting up a new app is going to give you way too much work just to get started. So you'll need to find a boilerplate with server side rendering and fork it. There are way more opportunities for security issues when you increased the surface area of your app's responsibilities. There will be updates to this boilerplate and you will have to merge them into all of your apps. I hope you like manually updating files and resolving merge conflicts on files you don't really understand…

We set out to resolve these problems when we built GlueStick (https://github.com/TrueCar/gluestick/). It's a CLI that allows you to quickly generate new apps using all of the tools we like to use on React applications. You have generators for creating containers (smart components hooked up to redux), components, and reducers. Redux is set up out of the box. You have server side rendering out of the box. We also push as much of the boiler plate code into the GlueStick module as we can. This lets you easily get performace and security updates as well as new features by simply updating the node module. You also get a sane folder structure so that all of your apps built with this tool will be easy to navigate.

We built this tool at TrueCar but we open sourced it. That means you can take it and make it your own, contribute back if you want to improve it and you can rest assured that it is backed by a big company that is heavily invested in seeing it succeed.

Re: Things every React.js beginner should know

#99

Post by aikah »

taytus wrote: post #55
andreyvit wrote: post #48

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.

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

No, because PHP still work that way (hypertext pre-processor) and Yes because, PHP has frameworks that makes PHP work like other solutions (Ruby,Python,Java + frameworks), but one still need a And again, a lot of PHP developers despise these frameworks and question their usefulness. In theory, they are right since PHP is a template language which goal is to render text content, and separation of concerns can be easily achieve without a complex framework in the case of a web application. In practice a framework makes large codebases more maintainable, no question.

PHP is a strange beast. It's somehow rigid like Java, at least more rigid than most dynamic languages, it's a dynamic language, and a template language and it keeps on getting stuff from Java like languages (PHP 7).

It's ironic that PHP was created because its author kind of found Perl too difficult to use for web dev, then wasn't taken seriously by pros then tried to imitate Java in some ways to feel more professional and now is on part with Perl in terms of complexity, while half of the PHP community praises over engineered codebases often found in the JEE world.

Re: Things every React.js beginner should know

#100

Post by escherize »

aikah wrote: post #91
matt4077 wrote: post #79

Earlier quoted context omitted.

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…

> ... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning. then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty ) so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists…

I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following.

Here's a function that always returns true - but it could do any kind of data access. It is just plain Clojure.

    (defn selected? [] true)
Here is a datastructure that represents html:

    [:h2 {:class (when (selected?) "selected")} "Hello"]
Calling the function hiccup.core/html on that datastructure yeilds an html string like this:

    "Hello"
So that's great for _strings_ right? But there is an awesome library for ClojureScript called Reagent. And it uses those simple datastructures to generate react components!! I put some more examples at: http://hiccup.space
Post reply on HN