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

Simple React Patterns

lucasmreis.github.io

Post reply on HN
Print view View original

11–20 of 87 posts

Re: Simple React Patterns

#11

Post by cname »

personomas wrote: post #5
dunstad wrote: post #3

Earlier quoted context omitted.

React explicitly discourages using inheritance with components, instead promoting composing components together like functions. You're also encouraged to keep them stateless if possible, so they create the same output for the same input. I'll need some convincing that functional programming is on its way out in JavaScript.

Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.

I thought `createClass` does/did something essentially similar to what `class` does in ES6. Not having to use a framework's custom class-creation machinery doesn't seem like a big loss to me or like it is has anything to do with functional programming.

Re: Simple React Patterns

#12

Post by acemarke »

cname wrote: post #11
personomas wrote: post #5

Earlier quoted context omitted.

Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.

I thought `createClass` does/did something essentially similar to what `class` does in ES6. Not having to use a framework's custom class-creation machinery doesn't seem like a big loss to me or like it is has anything to do with functional programming.

Yep. It also had some differences in behavior. `createClass` auto-bound functions so that `this` always pointed to the component instance, and it supported mixins.

The React team now encourages functional forms of composition rather than use of mixins, so that's another reason why React.Component doesn't support them. The lack of automatic method binding has certainly been a major pain for people learning and using React, but it also means that there's no "magic" involved. The Stage 3 Class Properties syntax is the recommended way to ensure that methods are bound properly, and there's plenty of other possible solutions as well.

Re: Simple React Patterns

#13

Post by always_good »

personomas wrote: post #6
personomas wrote: post #5

Earlier quoted context omitted.

Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.

In React v0.13 https://reactjs.org/blog/2015/03/10/react-v0.13.html , they claimed the reason for the switch is because the `class` syntax is for "more flexibility." What can you do with the `class` syntax that you can't do with the functional syntax? Furthermore, you can generate React code much easier with the functional syntax than with the class syntax. Also, the functional syntax has mixins and other ways to com…

Seems like a weird thing to miss for someone who ostensibly prefers functional programming.

For example, people here will talk about `function User() {}` like it's the pinnacle of amazing abstraction. Because it has the word "function" in it or something.

There's nothing functional about that to me. Mutating the prototype and dealing with the implicit `this` variable in your functions is about as far away from functional programming as you can get.

Meanwhile Javascript just gets more and more functional, from the mindshare of higher order functions/components gaining traction to the @decorator transformation to the Promise 'monad'. It just gets better and better.

I have a hard time taking anyone seriously who doesn't recognize the pain that `class` solved in the ecosystem whether you personally decide to use it or not. People have been writing OOP code in Javascript since day one, just with some of the worst idiosyncrasies of all OOP languages.

Re: Simple React Patterns

#14

Post by bjeanes »

acemarke wrote: post #10
personomas wrote: post #6

Earlier quoted context omitted.

In React v0.13 https://reactjs.org/blog/2015/03/10/react-v0.13.html , they claimed the reason for the switch is because the `class` syntax is for "more flexibility." What can you do with the `class` syntax that you can't do with the functional syntax? Furthermore, you can generate React code much easier with the functional syntax than with the class syntax. Also, the functional syntax has mixins and other ways to com…

At the moment, React does not yet have support for stateful functional components. It's something they've said they would _like_ to research and implement down the road, but right now, component state and lifecycle methods requires class components.

Or the use of something like recompose[1]'s `lifecycle` function[2].

1: https://github.com/acdlite/recompose

2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....

Re: Simple React Patterns

#15

Post by acemarke »

bjeanes wrote: post #14
acemarke wrote: post #10

Earlier quoted context omitted.

At the moment, React does not yet have support for stateful functional components. It's something they've said they would _like_ to research and implement down the road, but right now, component state and lifecycle methods requires class components.

Or the use of something like recompose[1]'s `lifecycle` function[2]. 1: https://github.com/acdlite/recompose 2: https://github.com/acdlite/recompose/blob/8c4ac2e4/docs/API....

Yeah, although that itself is implemented internally using an ES6 class:

https://github.com/acdlite/recompose/blob/8c4ac2e4a4cd8d60c8...

Re: Simple React Patterns

#20

Post by jbaudanza »

The problem with resolving promises inside of `componentDidMount` is that there is no way to cancel those promises. If the component is unmounted, and then setState is called, it will generate an error (or a warning. I can't remember).

Facebook discusses this on its blog: https://reactjs.org/blog/2015/12/16/ismounted-antipattern.ht...

I've been using Observables which, in my experience, bind a little cleaner than Promises to React components.

Post reply on HN