Move API calls on community page to client side

[iAdramelk]

Right now on community we fetch data from APIs inside getInitialProps it locks page render until we get all responses and also prevents us from caching renders results for this page as static html.

This PR moves these requests to the client side.

[shcheklein]

@fabiosantoscode PTAL :)

[fabiosantoscode]

A bunch of nitpicks and a typo. It looks good to me.

[fabiosantoscode]

Out of scope: maybe we should reject the promise when there's a non-200 response?

[iAdramelk]

It's mostly a question of there to handle rejections. We can do it either here or in components themselves. For now I decided that it will probably be easier to do there them increase components size.

P. S. I like your idea to transforms API calls to custom hooks, it will solve this problem and they can also have error state in them that components can use. I will try to convert them to custom hooks now.

[fabiosantoscode]

I see what you mean.

But maybe a non-200 response should have the same treatment as an error. This decreases the amount of outcomes the function may have. Right now, it's [error, undefined, response]. If we treat non-200 as an error it's only [error, response].

[fabiosantoscode]

nit: perhaps we could use a custom hook for these API calls, to keep things consistent:

const useAPICall = (apiFn, ...args) => {
  const [loading, setLoading] = useState(false)
  const [result, setResult] = useState(null)

  useEffect(() => {
    setLoading(true)
    setResult(null)
    apiFn(...args).then(result => {
      setLoading(false)
      setResult(result)
    })
  }, [apiFn, ...args])

  return { loading, result }
}

// ...
const topics = useAPICall(getLatestIssues, /* args for API call can go here */)

topics.loading // bool
topics.result // any

[iAdramelk]

Good idea, I'd probably would add error state here too.

[iAdramelk]

@fabiosantoscode Rewrote with hooks, please check.

[jorgeorpinel]

LGTM. Minor language suggestions below.

p.s. sanity check on https://dvc-landing-async-commu-rmgs1p.herokuapp.com/community also looks good. I can see the blog, discourse, and github calls in Network tab.

[fabiosantoscode]

Looks good.

The fact that we have to write so much code for this makes me sad we can't inspect promises from the outside. We would be able to read the result, error and whether it's resolved.

[shcheklein]

@fabiosantoscode

The fact that we have to write so much code for this makes me sad we can't inspect promises from the outside. We would be able to read the result, error and whether it's resolved.

could you elaborate please?

[fabiosantoscode]

@shcheklein

Just an aside. But you can't inspect a promise's completion state from the outside (without .then and .catch), like promise.isFullfilled or promise.isRejected, or get its value. If that was the case, we could use that as a standard object and pass it around.