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.
Simple React Patterns
51–60 of 87 posts
Re: Simple React Patterns
#52Re: Simple React Patterns
#53Earlier 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.
Re: Simple React Patterns
#54The 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…
Re: Simple React Patterns
#55The 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…
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).
Re: Simple React Patterns
#56Earlier 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.
Native promises do not have a "real" cancellation API (no 3rd path besides resolved and rejected) but you can mimic the functionality by rejecting with a dedicated error type, or use another promise as a cancellation token for example.
fetch(), which uses promises as return type, do not support aborting requests, as discussed [here](https://github.com/whatwg/fetch/issues/447) but the [old XMLHttpRequest does](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...).
Aborting is specific to HTTP requests, it's stopping the connection to the remote server (so technically impossible to implement with the current APIs as you said). Cancelling a promise is just stopping all onResolved continuations to be called, so it can be implemented in several different ways as I explained above.
The end result if you use a classic cancellation wrapper on a fetch() promise is that the onReject continuations will be called immediately with a specific reason. The HTTP request will continue to the end (no abort), but the response will be ignored.
In the case of the react library I mentioned, both the onResolved and onReject continuations will be ignored if cancelled, it's the subtlety that allows the component to be garbage collected (and probably why the author decided to call that "thrashable" as opposed to "cancellable" to mark the difference).
Re: Simple React Patterns
#57Earlier 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…
Re: Simple React Patterns
#58The 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…
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).
The React lifecycle has `componentDidMount` for doing stuff (at most once) after rendering.
Re: Simple React Patterns
#59The 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…
Re: Simple React Patterns
#60Part of me is sad that Javascript has now been made OOP, after a majority of efforts pushing the balance towards becoming more and more functional (e.g. PureScript) only a few years ago.