Live data from Hacker News

Simple React Patterns

lucasmreis.github.io

51–60 of 87 posts

Re: Simple React Patterns

#51
post #28
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.

This is pretty straightforward es6. The difference between =>{} and just => is confusing at first. One is a function body and the other is an implied return statement.

Re: Simple React Patterns

#52
Correct me if I'm wrong, but these patterns don't seem very much like a Redux way to do things. A lot of things feel somewhat implicit too. For example, I stopped just spreading my state into the child component, opting to be explicit nearing verbose instead.

Re: Simple React Patterns

#53

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.

You don't have to cancel the fetch request, you just have to cancel its callback.

Re: Simple React Patterns

#54

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…

In Android (for example), one would use an observable stream bound to the lifecycle of the host. Most folks do this using Rx and add a custom operator for unsubscribing on the host DESTROY event.

Re: Simple React Patterns

#55

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…

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).

Re: Simple React Patterns

#56

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.

We're talking about several different things:

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

#57

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…

I suppose it isn't really a GUI but it does manage them.

http://xmonad.org/

Re: Simple React Patterns

#58

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…

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.

Re: Simple React Patterns

#59

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.

Re: Simple React Patterns

#60
post #2

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.

ClojureScript's re-frame[0] is my favorite way to React, honestly. PureScript's halogen is also pretty nice. Re-frame has a built-in, functionally pure way to do ajax and side-effects, too, which comes in pretty handy.

[0] https://github.com/Day8/re-frame

Post reply on HN