41–50 of 87 posts
Earlier quoted context omitted.
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.
This is a shorthand for function (r) { return r.json()} Note the extra return. We return the JSON decoded response that is our planet. and use its value to set state if no error occured
Earlier quoted context omitted.
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…
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 describe…
I'm on the highway to Elm
(or reason, or purescript, either way towards a language with first-class sum types support, that's just so convenient)
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.
Nothing "terrible", absolutely native (both since the keyword is part of JS and since the implementation is based on prototypes that have been with JS since the beginning), and fits perfectly.
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.
so res => res.json() is just like having a callback like:
function(res) { return res.json() }
and the next part in the then() chain, takes that result as "planet".
Basically, that last part of the chain, has a signature like:
(function callback(...), function errorCallback(...))
and the callback part gets the result of the previous step as "planet" (if all went ok). If there was an error in the previous steps of the chain, the errorCallback would get called, with the exception passed in as "error".
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…
this.cancelOnUnmoun(new Promise(...)).then(...)Part 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.
Earlier quoted context omitted.
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.
I've thought it's just technically impossible (no API to do so) to cancel a `fetch` request in progress.
Part 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.
actually once redux is introduced to react it's very very very functional.. so hold the sadness
Look at the Reason team, with their Reason-React implementation. Cheng Lou seems to actively dislike a single store that Redux is, and, if anything, co-locates stores to stateful components.
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…