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

31–40 of 87 posts

Re: Simple React Patterns

#31

Post by stevula »

TekMol wrote: post #28
pdyck wrote: post #26

Earlier quoted context omitted.

When the component is mounted on the page, a planet is fetched from an api. Then the response body is parsed to JSON. After that the object is added to the component state. When there was an error it is added to the state instead.

Then the response body is parsed to JSON The "res => res.json()" call? But what does this do? res seems to be used nowhere and just discarded without any side effects.

`res.json()` is the return value of the first `then` block, which is then passed to the second `then` block as `planet` (if json parsing doesn't throw an error).

Re: Simple React Patterns

#32

Post by Secretmapper »

TekMol wrote: post #29
Secretmapper wrote: post #25

Earlier quoted context omitted.

It fetches data from an endpoint then sets component state based on the response

Well, it makes a http request but it seems to do nothing with the data returned.

The data is set as component state

  .then(
        planet => this.setState({ loading: false, planet }),
        error => this.setState({ loading: false, error })
       );

Re: Simple React Patterns

#33

Post by loevborg »

Guillaume86 wrote: post #27
jbaudanza wrote: post #20

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

Yes there was a whole discussion in a github issue about the correct pattern to solve this. Creating and guarding against a `isMounted` field in your `.then()` callbacks means you prevent garbage collection of the unmounted components. An easy solution is to use cancellable promises (with some subtleties to allow garbage collection). There's an implementation which take care of this properly here (provides an HoC): h…

When you say "cancellable promises", that means that you cannot use native JS promises, correct?

Re: Simple React Patterns

#34

Post by methyl »

The author claims the article [1] says render props are anti-pattern, while this is not true. The only thing that's called an anti-pattern there is "children as a function". If you use properly named render prop other than children, they seem to be fine with that.

Will be good to correct that since it's pretty confusing.

[1] http://americanexpress.io/faccs-are-an-antipattern/

Re: Simple React Patterns

#35

Post by girvo »

hungerstrike wrote: post #22
always_good wrote: post #13

Earlier quoted context omitted.

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

People also write tons of bad functional code with JS. It gets worse and worse the more that people keep following this cargo cult of HOCs and functional programming. The obsession with using HOCs for passing a simple variable around is particularly absurd. Importing objects with methods (or even just a namespace with functions) is way, way cleaner than importing every function seperately. Which stable and widely use…

ReasonML and ReasonReact agree with you: instead of HOCs, they prefer using standard functions, explicit “self”, and just passing things down through props. It’s quite a breath of fresh air really.

Re: Simple React Patterns

#36

Post by pgkl »

TekMol wrote: post #28
pdyck wrote: post #26

Earlier quoted context omitted.

When the component is mounted on the page, a planet is fetched from an api. Then the response body is parsed to JSON. After that the object is added to the component state. When there was an error it is added to the state instead.

Then the response body is parsed to JSON The "res => res.json()" call? But what does this do? res seems to be used nowhere and just discarded without any side effects.

res => res.json() returns the result of res.json()

That function is thenable so following it .then is called and the result or error is passed to the first or second function respectively.

Re: Simple React Patterns

#37

Post by Cthulhu_ »

blumomo wrote: post #18

The Container/View Pattern in this article, isn't this MVC?

You could argue it's a variation thereof, more like MVVC (Model View ViewController) maybe. In React you only really have the View layer. In this case, there's two views, a 'functional' view (the ViewController) and the 'presentation' view (the View itself).

I guess the main difference is that in MVC, the view and controller are two separated entities (side-by-side), while in React it's embedded (Controller wraps around View).

Re: Simple React Patterns

#38

Post by Guillaume86 »

loevborg wrote: post #33
Guillaume86 wrote: post #27

Earlier quoted context omitted.

Yes there was a whole discussion in a github issue about the correct pattern to solve this. Creating and guarding against a `isMounted` field in your `.then()` callbacks means you prevent garbage collection of the unmounted components. An easy solution is to use cancellable promises (with some subtleties to allow garbage collection). There's an implementation which take care of this properly here (provides an HoC): h…

When you say "cancellable promises", that means that you cannot use native JS promises, correct?

You can, you just need to wrap it when used inside a react component.

Re: Simple React Patterns

#39

Post by fky »

After 2+ years of writing React most of the day every day with a lot of different patterns coming in and falling out of love in our app, our experience falls almost exactly in line with this. It's simpler than I would have imagined from when we first started using React/Redux and handles the most complex interfaces our app has.

My favorite part is how he models the different states the component can have. He describes the different states in a comment block but we found it even nicer to use Flow and disjoint unions to help the developer avoid impossible states which we learned from a talk by Jared Forsyth: https://www.youtube.com/watch?v=V1po0BT7kac. Another huge boon in productivity and so simple and obvious in hindsight!

Re: Simple React Patterns

#40

Post by bfred_it »

TekMol wrote: post #28
pdyck wrote: post #26

Earlier quoted context omitted.

When the component is mounted on the page, a planet is fetched from an api. Then the response body is parsed to JSON. After that the object is added to the component state. When there was an error it is added to the state instead.

Then the response body is parsed to JSON The "res => res.json()" call? But what does this do? res seems to be used nowhere and just discarded without any side effects.

If it makes it easier to reason about, it's equivalent to:

    // The Promise resolves when the server starts responding
    const response = await fetch(…);
    
    // The Promise resolves when both the transfer and the JSON parsing ended
    const body = await response.json();
So, yes, `response` is only used once and then discarded.

`fetch()` may fool you into thinking that it resolves when the request is complete, but it's always a 2-step operation (unless you start implementing a streaming interface, then it's more than 2 steps)

Post reply on HN