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

71–80 of 87 posts

Re: Simple React Patterns

#71

Post by always_good »

ihsw2 wrote: post #58
FLUX-YOU wrote: post #55

Earlier quoted context omitted.

Where is the typical place to put initial fetches? I've been setting empty state and then calling a method at the end of a constructor which ultimately results in a promise that calls setState with the data. But I would never do something like that in, say, the constructor of a WPF/UWP windows app as those have "Loaded" or "Loading" events of some kind (which is parallel to componentDidMount).

`componentDidMount`, which is after a React component has been rendered. This contradicts the parent commenter directly but I'm fine with that. The React lifecycle has `componentDidMount` for doing stuff (at most once) after rendering.

I don't understand what you're saying.

Once the component mounts, then it can be unmounted. The upstream comment is talking about when you have a promise that is still running after unmount.

Re: Simple React Patterns

#72

Post by always_good »

drdaeman wrote: post #48
Guillaume86 wrote: post #38

Earlier quoted context omitted.

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

How? I've thought it's just technically impossible (no API to do so) to cancel a `fetch` request in progress.

For example, you can wrap a promise such that when it finally resolves, it checks an isCancelled flag and rejects instead so that your .then callbacks aren't run.

It's not about cancelling any potential inflight action within the promise itself.

In this case, you don't want the callback to run after the react component unmounts, nor do you want to hold a reference to the component:

    promise
        .then(value => this.setState({ value }))

Re: Simple React Patterns

#73

Post by whistlerbrk »

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

Protect the setStates in the callback with a conditional switch that gets flipped off in componentWillUnmount.

Not clear on what you're saying, pseudocode?

Re: Simple React Patterns

#74

Post by always_good »

notaboutdave wrote: post #16

That ~30 line component should be reduced to something resembling this: const PlanetView = ({planet}) => {planet ? planet.stuff : 'Loading...'}

It's demonstrating a component that needs I/O, so I'm not sure how refactoring it into one that needs its parent to do the I/O helps the demonstration.

Re: Simple React Patterns

#75

Post by topgunsarg »

whistlerbrk wrote: post #73
pcmaffey wrote: post #59

Earlier quoted context omitted.

Protect the setStates in the callback with a conditional switch that gets flipped off in componentWillUnmount.

Not clear on what you're saying, pseudocode?

In componentWillUnmount, set a var componentUnmounted true. In componentDidMount in the callback for the fetch, check for componentUnmounted before setting state for an error or whatever you want to do.

Re: Simple React Patterns

#76

Post by vinnymac »

kowdermeister wrote: post #24
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.

Classes are perfectly fine in JS, they are just syntactic enhancements for managing prototypes more easily.

Not sure what you mean by 'just syntactic enhancements'. Check this out https://esdiscuss.org/topic/javascript-vision-thing#content-...

Re: Simple React Patterns

#77

Post by travmatt »

topgunsarg wrote: post #75
whistlerbrk wrote: post #73

Earlier quoted context omitted.

Not clear on what you're saying, pseudocode?

In componentWillUnmount, set a var componentUnmounted true. In componentDidMount in the callback for the fetch, check for componentUnmounted before setting state for an error or whatever you want to do.

Set a variable... set a property in the component state? Or set a static variable on the class?

Re: Simple React Patterns

#78

Post by MPiccinato »

I am always intrigued when I come across an article like this, after having done 2+ years of React development, and have never seen these patterns (Provider Pattern), nor seen them debated (Render Props). I do pay attention to the community here and there, and constantly poke around open source react libraries.

I tend to bring in patterns from iOS development, such as Delegates, especially when using React Native, and is really useful when using Flow or TypeScript.

We heavily rely on the Material-UI library (https://material-ui-next.com/) and have brought a lot of their patterns into our libraries, mostly how reusable components are composed.

Re: Simple React Patterns

#79

Post by pcmaffey »

travmatt wrote: post #77
topgunsarg wrote: post #75

Earlier quoted context omitted.

In componentWillUnmount, set a var componentUnmounted true. In componentDidMount in the callback for the fetch, check for componentUnmounted before setting state for an error or whatever you want to do.

Set a variable... set a property in the component state? Or set a static variable on the class?

I use a static var on the class.

  componentDidMount() {
   if (!this.unmounted) ...
  }

  componentWillUnmount() {
   this.unmounted = true
  }

Re: Simple React Patterns

#80

Post by [deleted] »

MPiccinato wrote: post #78

I am always intrigued when I come across an article like this, after having done 2+ years of React development, and have never seen these patterns (Provider Pattern), nor seen them debated (Render Props). I do pay attention to the community here and there, and constantly poke around open source react libraries. I tend to bring in patterns from iOS development, such as Delegates, especially when using React Native, an…

[deleted]
Post reply on HN