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

Re: Things every React.js beginner should know

#141

Post by shaneckel » Mon, Jan 25, 2016, 6:13 PM UTC

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 depends on your perspective. If you're building an application that passes disjointed components around, then yes, you can combine the three (js,html,css) into a self reliant container. If you're building a website that is basically a series of pages, that is part of a book per say, then it doesn't quite make sense. I would say 10 years ago it was not common to think of the web as a platform. Over the last 5 years using the dom as platform and js as the source code has become much more predominant.

Whether the scope of your business can be used by this architecture would determine whether it would come up in your day to day.

Re: Things every React.js beginner should know

#142

Post by saidajigumi » Mon, Jan 25, 2016, 6:14 PM UTC

stickperson wrote: post #94

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.

I have to admit I find the author's insistence on defining a component as a function to be a big red herring. Instead, it feels like the presence of JSX outside of the component's render() method is the (potential) code smell.

It doesn't help that several popular React & React Native tutorials out there, for understandable simplicity, opt to use "renderSubThing" methods. In the examples and in my own code so far, I mostly find those sub-render methods to be a proxy for "I don't want to break stride to make a new component, so I'll jam this stuff in a method and refactor later." That's great, so long as the refactor actually happens.

(Hm, that'd be a great candidate for a vim refactoring plugin...)

Re: Things every React.js beginner should know

#143

Post by ergothus » Mon, Jan 25, 2016, 6:14 PM UTC

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 always coupled, whether you have them in separate files or not. So in that sense, all React is doing is admitting a truth.

While embracing the coupling of that mix, React is ALSO pulling out a lot of logic: React encourages one source of truth (the state is in one spot, and drives the markup, but you never consult the markup to determine the state). An error that is commonly seen in, for example, jQuery apps, is that some state is hanging around in application variables, while other times it's in the current markup state, and the app will consult the markup to see what's happening. That's not a built in jQuery problem, it's just a common problem of implementation.

I'm not sold entirely on the React boat, but it does seem to directly address problems that I've encountered in other systems, and I expect whatever comes next will build from React principles rather than reject them.

Re: Things every React.js beginner should know

#144

Post by spion » Mon, Jan 25, 2016, 6:14 PM UTC

andreyvit wrote: post #48

spion wrote: post #23

Earlier quoted context omitted.

This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don't keep track of the reasons why a law came into use in the first place, we might miss the moment where it might not apply anymore (we wont even know, really) While I'm not entirely…

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.

See the problem with this explanation is again, it doesn't explain the reasons why this is bad. I'm not saying the reasons don't exist - on the contrary I agree they're very much real. However I don't think "view logic, domain/business logic and database boilerplate code are intermixed in a single file" qualifies as a straightforward, logical explanation. It simply doesn't answer the "why" question at all.

Let me try and cover some of the reasons why. I'm sure you know about these reasons (and can probably list more), my goal is just to present an example of what I consider to be a straightforward logical explanation:

If domain/business logic is mixed with view logic, then it would not be possible to reuse the same logic in a different view. These changes happen more often than anticipated: for example, a PHP project that has the view logic separated from the domain/business logic can more easily get an API (a HTML is one view, a JSON API would be just another view)

Additionally separating database code from business logic lets you switch databases more easily or to give you multiple ways to access the data. For example, data may be directly fetched from an SQL database initially, then its determined that this is too slow and results need to be cached in Redis. If there is no separate code for the data access layer, you would need to locate every database query and make sure it queries the cache first.

So this is what qualifies as a straightforward, logical explanation for me: lets assume the opposite statement was true, then we demonstrate how this leads to a bad situation and why its bad (more bugs, more work, and so on).

Another would be doing a case study: we did X (mixed business logic and templates in this way), then when we wanted to do Y (present a different view V) we had to not only write new code (for the new view) but deal with this problem (uncouple the existing logic from the existing view). If we originally did otherwise (wrote the logic separately) this would've been the same or similar amount of work (demonstrate this) yet later we would not have to do the hairy decoupling (which took Z amount of time and caused N bugs)

I think the whole industry would do much better if we focused more on actual specific examples and case studies of problems and drawbacks of different approaches rather than giving vague descriptions of the current state and claiming its "bad". Its just not helpful at all. There is so much reinventing the wheel in our profession simply because we are not communicating knowledge effectively. Frankly, most of it reminds me of religious dogma.

Re: Things every React.js beginner should know

#145

Post by tlrobinson » Mon, Jan 25, 2016, 6:17 PM UTC

toddmatthews wrote: post #41

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?

Hence why Peter Hunt (react.js developer) named his presentation "Rethinking Best Practices" https://www.youtube.com/watch?v=DgVS-zXgMTk

I love how he named that presentation after a snarky Tweet from when React was announced: https://twitter.com/cowboy/status/339858717451362304

Re: Things every React.js beginner should know

#146

Post by Moru » Mon, Jan 25, 2016, 6:28 PM UTC

mattmanser wrote: post #60

ChrisArgyle wrote: post #47

Earlier quoted context omitted.

The big reason I remember from my PHP days (late 90s early 2000s) is that you want to separate design from development. Graphic designers were expected to know HTML/CSS while developers focus on PHP.

That's never really been true. Graphic designers rarely knew HTML/CSS in the old days.

I still get everything as a .jpg. Or a photoshop image if I'm lucky.

Re: Things every React.js beginner should know

#147

Post by tlrobinson » Mon, Jan 25, 2016, 6:39 PM UTC

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?

One way to think about it is JSX is just another templating language that happens to be a superset of JavaScript. You are free to use as much or as little logic as you like, but the trend is definitely moving towards keeping most components simple and free of complex logic.

With "stateless functional components" (added in React 0.14) and ES6 you can have "templates" that look like this:

    export default ({ title, author, body }) =>
      
        {title}
        By {author}
        {body}

I wonder if anyone has written a linter to enforce a "logic-less" dialect of JSX? Perhaps allowing specific looping and conditional idioms like:

    { array.map(object =>
      {object.whatever}
    ) }

and

    { foo ?
      yes
    :
      no
    }

Re: Things every React.js beginner should know

#148

Post by toolz » Mon, Jan 25, 2016, 6:40 PM UTC

mst wrote: post #138

toolz wrote: post #96

Earlier quoted context omitted.

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.

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.

Re: Things every React.js beginner should know

#149

Post by tlrobinson » Mon, Jan 25, 2016, 6:47 PM UTC

EvanPlaice wrote: post #35

awjr wrote: post #27

Earlier quoted context omitted.

If you are learning MVC, only learning V is not going to get you far. I do wonder if things like Typescript can solve a lot of the speed issues.

Why would you assume Typescript solves any speed issues? Typescript's type checking adds overhead just the same. So it's also a good idea to disable checks during runtime.

TypeScript doesn't do any runtime checks, AFAIK. In fact, that's one of their stated goals: "Impose no runtime overhead on emitted programs." https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Re: Things every React.js beginner should know

#150

Post by adamors » Mon, Jan 25, 2016, 6:48 PM UTC

jjnoakes wrote: post #124

bpicolo wrote: post #114

Earlier quoted context omitted.

And without JS you don't get real applications on the web. Dumb text is fine for web 1.0, 2.0, but modern web applications are expanding far beyond that. Are there ways to be abusive with JS? Sure. But JS is what enables web applications as opposed to just having text-on-page (newspaper 2.0).

This is simply not true. Ignoring the fact that "real application on the web" has no definition... very useful web pages can be created without JavaScript, and they can (quite easily) interact with the user by taking input and updating what they display. Why is something like that useful? Accessibility, security, backward compatibility, ...

Yes that's why they specifically said web applications not pages. You cannot create web application without JS.