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

151–160 of 247 posts

Re: Things every React.js beginner should know

#151

Post by recursive »

preinheimer wrote: post #111
aikah wrote: post #99

Earlier quoted context omitted.

> 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…

I have no idea how starting with <?php in a file is relevant. Should we also start mocking languages that expect a given file extension?

Because it demonstrates that that pattern does not follow the default mode of operation for the language.

Re: Things every React.js beginner should know

#152

Post by gemma »

aikah wrote: post #125
preinheimer wrote: post #111

Earlier quoted context omitted.

I have no idea how starting with <?php in a file is relevant. Should we also start mocking languages that expect a given file extension?

My point is that PHP renders text first and foremost, writing code in PHP is "opt-in" somehow. An HTML file for instance is a valid PHP file. AFAIK an HTML file isn't a valid Ruby or Python file. You don't need to tell the interpreter to kick in at first place. But that's not the main idea I tried to convey in my comment.

Right, your comment argued that "view logic, domain/business logic and database boilerplate code intermixed in a single file" is not "ancient history in the PHP world". Which it is, regardless of the `<?php` tag at the top of all the files. How a source file is processed has no impact on how programmers choose to model their applications.

Re: Things every React.js beginner should know

#153

Post by gemma »

andreyvit wrote: post #62
mattmanser wrote: post #58

Earlier quoted context omitted.

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...

I explicitly do _not_ state that it applies to React, because there's no domain logic in React components. (Or at least there shouldn't be. It is certainly possible to write a spaghetti component that would do everything.)

> It is certainly possible to write a spaghetti component that would do everything.

So...like PHP, then?

Re: Things every React.js beginner should know

#154

Post by Reedx »

todd3834 wrote: post #98

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 som…

Nice, I like this a lot. I think it's the cleanest and most concise approach I've seen re: universal React/Redux.

Is there a way to override or extend the webpack config though? (without having to fork it) What if some projects need different loaders or want to use code splitting, etc?

Re: Things every React.js beginner should know

#155

Post by munro »

lmm wrote: post #132
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…

> You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates. No you don't. Look at Wicket for how to do this right: everything is a component, the only thing[1] your templates contain is a) markup (which is 100% valid, using a namespace for the only wicket-specific part) and b) ids that indicate that a given tag will be replaced with a component. Everything else is hand…

When the parent says view, they're not talking about "a) markup", they're talking about the thing the user is looking at.

> b) ids that indicate that a given tag will be replaced with a component

With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user.

With JSX, keeping all of this code closer together that is intrinsically tied together increases cohesion, by definition. Subjectively, this makes it easier to manage UI because one only have too check one place for all the pieces. For further exploration of this idea, check out the intro of this video on separation of concerns vs technology. [1]

On a separate point, it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI. Time is removed from the equation, which also makes things easier to reason about.

[1] https://www.youtube.com/watch?time_continue=275&v=x7cQ3mrcKa...

Re: Things every React.js beginner should know

#156

Post by mst »

toolz wrote: post #148
mst wrote: post #138

Earlier quoted context omitted.

I suspect it's because people regard the implied foreach loop of data-scope to not count as logicless. Personally I can see the arguments both ways, and have concluded that simply ensuring I'm using the same definition of logicless as the people I'm talking to is the best answer.

Ahh, well I never claimed it was logicless. I claimed the templates were logicless, and they are. The logic is kept separate inside the processors that you bind to the template.

Except the -scope part means that the foreach-ness is indicated by the template, so people consider that to be not-logicless.

I understood your claim fine. I'm trying to explain why it might be considered false (and I did already say I consider the arguments each way basically hair splitting).

Re: Things every React.js beginner should know

#157

Post by marknutter »

ergothus wrote: post #143
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?

It does indeed go against years of advice, but only if you look at it from too far out: (Note: I've minimal Angular experience so I won't comment on that. I've spent the last year on React) The real problem is mixing business logic and presentation, not mixing HTML and JS. React is purely presentation & presentational logic (or should be, you can of course implement it poorly) For Presentation, the HTML and JS are al…

> For Presentation, the HTML and JS are always coupled, whether you have them in separate files or not.

Absolutely not. Back when we were all just using jQuery, you could run $('.some-class').myWidget() to activate a widget on any element matching the query. There was no need to couple the implementation of the widget with the element to which it was applied.

If the widget had some internal element construction to do then yes, I would agree, it makes sense to have it be part of the same file, and this was often done with string concatenation back in jQuery days.

However, there is still value in being able to share the same html template across multiple models. You may have a general tabular structure you want to adhere to app-wide but you may want to implement different dynamic logic to those tables in different places. Now you're faced with having to copy/paste the same template over and over in React to accomplish the same task, or you have multiple mixins that define different behavior which kind of defeats the purpose of having the logic and the markup live together.

Re: Things every React.js beginner should know

#158

Post by rootlocus »

jwarren wrote: post #108
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 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.

Following that line of reasoning, everyone is actually writing machine code.

Re: Things every React.js beginner should know

#159

Post by munro »

escherize wrote: post #100
aikah wrote: post #91

Earlier quoted context omitted.

> ... 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 t…

I love Clojure, but I'm tired of embedded DSLs, they're a dime a dozen. You can argue the benefits of Hiccup's syntax & s-expr all day, but it's still a different, and unpopular syntax for describing HTML.

The ability to copy snippets of HTML from web, or old code when refactoring, or from Clojure/Hiccup to another language & framework, or changes from developer tool, or familiarity for new engineers, or not having to care about what flavor of HTML is hip today is a huge productivity boost for me.

I would love to see push for template strings [1] in Clojure, it should be trivial with macros. It would only take some time for IDEs to catch up. They're good. So good they've even influenced Python 3 to add them.

    (defui my-component [x]
      "Hello")
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Things every React.js beginner should know

#160

Post by todd3834 »

Reedx wrote: post #154
todd3834 wrote: post #98

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 som…

Nice, I like this a lot. I think it's the cleanest and most concise approach I've seen re: universal React/Redux. Is there a way to override or extend the webpack config though? (without having to fork it) What if some projects need different loaders or want to use code splitting, etc?

We have plans to implement this. I don't think it will be too hard to implement. The hard part will be coming up with a clean approach for developers as they build apps. It is on the list of things we would like to add. A PR for this would be greatly appreciated :)
Post reply on HN