Things every React.js beginner should know • Hacker News Board

Re: Things every React.js beginner should know

#221

Post by btdiehr » Tue, Jan 26, 2016, 12:21 PM UTC

marknutter wrote: post #157

ergothus wrote: post #143

Earlier quoted context omitted.

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…

> you could run $('.some-class').myWidget() to activate a widget

So we have obfuscated the functionality embedded in our HTML with jQuery calls in separated files. Is this what you mean by decoupled?

> Now you're faced with having to copy/paste the same template over and over in React to accomplish the same task,

This is nonsense. Have you ever... used React? I recommend not opining on something which you lack even the most basic knowledge about.

Re: Things every React.js beginner should know

#222

Post by hex13 » Tue, Jan 26, 2016, 12:50 PM UTC

Retozi wrote: post #13

didgeoridoo wrote: post #3

#10: This guide will be out of date in 3 months.

I really don't understand the underlying complaint of your comment that the React ecosystem is in constant flux (see what I did there?) I've been writing React SPAs for roughly two years now. Very few things have changed. The first app I've written roughly looks like the newest one. Couple of lessons learned here and there like everywhere else. Yes, there are many Flux libraries and different implementations. However…

The biggest advantage of this progress is that there is a lot experimentation with new kind of tools (for example Redux Dev Tools. This is fascinating. I mean Redux is great, but the fact that there are dedicated dev tools for this? Wow. I'm waiting for new tools (maybe every popular library from now on will have its own dev tools? Or maybe somebody will make universal dev tools for all React libraries?).

I think what's happening inside React ecosystem and this constant flux of innovations is not comparable with anything in the webdev before (maybe except Ruby community which is also pretty innovative).

Re: Things every React.js beginner should know

#223

Post by marknutter » Tue, Jan 26, 2016, 1:45 PM UTC

paulddraper wrote: post #214

marknutter wrote: post #206

Earlier quoted context omitted.

It amazes me how much the software industry is like the fashion industry. Do you honestly base your technology decisions on what brand names are attached to them?

Software is (mostly) about function. Fashion isn't. When something functions on massive scale, it's commendable, and worth looking at.

What does scale have to do with front-end development? Front-end code runs on the user's machine. And regardless, it's folly to make decisions based on wanting your code to scale to Facebook level usage.

Re: Things every React.js beginner should know

#224

Post by overgard » Tue, Jan 26, 2016, 3:16 PM UTC

paulddraper wrote: post #213

overgard wrote: post #210

Earlier quoted context omitted.

I don't think that's really true. Not to put words in his mouth, but the GPs assertion seems to be that library vs framework tends to not matter much other than in what it says about the individual, whereas my assertion would be that choosing small focused libraries has nothing to do with ego or imposter syndrome or whatever, I just don't want to learn a massive chunk of code if I can learn a small chunk of code and…

"I tend to prefer libraries over frameworks...they don't box me into patterns I don't want or need" You're confident that you're able to identify what you want and need, and how to get there. You don't need help or strong direction. In contrast, I worry about making the naive choice, and I trust that others have thought about this a lot more than me. So I tend towards things that have built-in best practices/assumpti…

Fair enough, I hadn't really thought of it from that angle, but I can see the value there

Re: Things every React.js beginner should know

#225

Post by samizdatum » Tue, Jan 26, 2016, 3:17 PM UTC

TranquilMarmot wrote: post #104

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…

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…

Razor is really quite different from React.

Razor seems to have been born out of a frustration someone had with writing

  return "" + model.name + "";

Razor is basically a DSL for C# string concatenation, where everything not escaped with an @ is a string literal to be concatenated. This means it's fairly unopinionated about structuring code. React, on the other hand, forces you to define components- ideally, pure functions from properties to JSX (which is just sugar for JS). This means composition is the default solution to everything. Razor doesn't place nearly as much emphasis on composable components, and the mechanisms it has for doing so, like helpers or calls to RenderPartial, are clunky and worlds away from the first-class component support of React.

While it's technically possible to write Razor code with a React-style focus on composition, the syntax and architecture of viewmodels/templates actively pushes you away from doing so. In my experience, most Razor ends up like a C# translation of PHP, and I think that's really the paradigm Razor inherited. Razor has been around since 2011, which significantly predates the Cambrian explosion of clientside js frameworks, so it makes sense.

Re: Things every React.js beginner should know

#226

Post by TranquilMarmot » Tue, Jan 26, 2016, 4:39 PM UTC

samizdatum wrote: post #225

TranquilMarmot wrote: post #104

Earlier quoted context omitted.

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…

Razor is really quite different from React. Razor seems to have been born out of a frustration someone had with writing return " " + model.name + " "; Razor is basically a DSL for C# string concatenation, where everything not escaped with an @ is a string literal to be concatenated. This means it's fairly unopinionated about structuring code. React, on the other hand, forces you to define components- ideally, pure fu…

Good point that it's hard to write nice and modular views with Razor; helpers and RenderPartial are pretty clunky and overall just hard to manage. I suppose it is pretty PHP-like...

Re: Things every React.js beginner should know

#227

Post by mercer » Tue, Jan 26, 2016, 5:31 PM UTC

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

I think you're right, but your last paragraph is crucial.

The reason I'm doing front-end development is because I enjoy it. I'm not doing it only to 'get shit done'. And part of that enjoyment means not always having to deal too much with other people's choices, because sometimes they feel like straitjackets.

So as long as the client doesn't suffer from me making choices based on enjoyment, I'm going to use RethinkDB, React for the back-end, and roll out my own custom-built CMS if I so desire. Because I'm responsible enough to know when this is okay, and it's just hella fun to do.

But yes, when in doubt lean towards the thing that has been tried and tested over your own (possibly disastrous) sources.

But also no, the most I've learned has been by making terrible choices and having to figure things out, truly figure things out myself instead of relying on frameworks from the start.

I mean, it's not like things will explode when we fail in the front-end world, generally speaking.

Re: Things every React.js beginner should know

#228

Post by mercer » Tue, Jan 26, 2016, 5:36 PM UTC

gemma wrote: post #153

andreyvit wrote: post #62

Earlier quoted context omitted.

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?

Not really. You're strongly coaxed into doing it the right way by design, which is not my experience with the old-skool PHP approach.

Re: Things every React.js beginner should know

#229

Post by munro » Tue, Jan 26, 2016, 5:37 PM UTC

lmm wrote: post #217

munro wrote: post #194

Earlier quoted context omitted.

> There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. Again, changing view to mean "template" is a strawman. > Wicket clearly separates its state into models > You do have to declare which changes update which UI (for performance reasons), Separating state isn't the same as no…

> Again, changing view to mean "template" is a strawman. Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. > Separating state isn't the same as no state. Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? > Also imperatively updating the UI on state changes is stateful. There's nothing imperative about it.…

> Call it what you like. The point is that clear separation between logic and markup can be done and is valuable.

You concede the original point. To your new point, saying something is valuable doesn't make it valuable. Why? It decreases cohesion, which is not good.

> Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go?

If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions.

> There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around?

Please do not dilute conversations on here by name calling. Imperative & state are basic computer science terms... o_O

Re: Things every React.js beginner should know

#230

Post by mercer » Tue, Jan 26, 2016, 5:38 PM UTC

gemma wrote: post #152

aikah wrote: post #125

Earlier quoted context omitted.

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.

Theoretically no, perhaps, but practically I think there is an impact.

I can't dump html into a .rb or .js file, so I'm less likely to do so as a beginner. On the other hand, starting out with php, that seemed like the logical thing to do. Because I could.