Enable hosting the site at non-root

[wchargin]

Various portions of the site currently assume that they are being served
from the root of the host. In other words, we assume that the public
path is /. This precludes hosting demos from a personal GitHub
repository like decentralion/sourcecred-demos.

A relatively straightforward fix is to thread the public path
configuration through whitherever it is required. Then, we can specify
the public path at build time: for instance, a demo for the Foo project
might be hosted at --public-path /sourcecred-demos/foo.

An alternative solution is to use relative paths throughout the
application, so that the public path does not need to be statically
known. This might require some care, but would probably be more robust.
For instance, this would let us serve instances of the site from an IPFS
gateway without needing control over the domain.

[wchargin]

Here’s an update about what I'm working on.

As part of enabling our site to be served from arbitrary gateways, I've
created a new implementation of the history@3 interface, which plugs
directly into our router. Getting the details right is critically
important, and it took some thought to figure out what the right
abstractions were. This, combined with the fact that history and
react-router together have a grand total of zero type definitions and
zero actual API references or specifications, suggests to me that the
module in question merits extensive automated testing.

Happily, it is the kind of thing for which it is possible to write
unusually good tests—both as core logic tests and a (nearly) end-to-end
test of a full React application, all within a normal Jest environment
(i.e., we don’t have to shell out to Webpack or anything). It’s taking
some time, but it’s going along well.

I considered adding Flow typedefs to history@3, which would mitigate
the problem somewhat. I decided not to do so for two reasons. First, the
module in question will not permeate the whole application: its use is
scoped to a few files (approximately two clients). Second, history@3,
like many libraries designed without types in mind, is difficult to
write good types for: it has “shortcuts” for “convenience” that
significantly complicate the API to a point that it is difficult to
usefully express in Flow.

If we eventually ditch react-router entirely (which might be a good
idea), we’ll still be able to use important parts of this module, which
is nice.

PRs to come. :-)

[wchargin]

Another technical update to explain the latest architecture.

Central to this issue is the Assets class introduced in #664, which
lets a client resolve a path like /favicon.png to either favicon.png
or ../favicon.png, depending on the route from which it’s being
rendered. Implementing this and keeping it in sync with the URL is not
trivial, but it is self-contained.

At some point, however, we need to use the Assets resolver. In
particular, our React components need to have access to an appropriate
resolver, so that they may include static assets like <img>s or fetch
API data like plugin graphs.

My initial approach to this was to use the React v16.3 Context API,
which would provide essentially a global variable with shadowing
semantics to a React subtree. That is, if our application currently
looks like this:

<App>
  <CredExplorerApp>
    <RepositorySelect />
    <PagerankTable />
  </CredExplorerApp>
</App>

then with the contexts model it would be changed to look more like:

<AssetsContext.Provider value={assets}>
  <App>
    <CredExplorerApp>
      <AssetsContext.Consumer>
        {(assets) => <RepositorySelect assets={assets} />}
      </AssetsContext.Consumer>
      <PagerankTable />
    </CredExplorerApp>
  </App>
</AssetsContext.Provider>

Thus, any component in the application tree can magically request
access to the contexts. (See #663 for slightly more detail.)

This is certainly convenient, and while global mutable state is
certainly to be avoided, it bears noting that this context is not
mutable, and even calling it “state” is a bit of a stretch—it’s more
like a prop that is automatically threaded down to the appropriate
consumers.

I implemented this design, and it worked in the expected fashion.
However, it was nigh impossible to test. This is primarily because
Enzyme’s support for this context API is pretty abysmal. This approach
would have basically required us to stop using shallow rendering
anywhere, in favor of always using mount, which means that we cannot
actually unit-test frontend components. The fact that we can
shallow-render has been critical to our testing practices, enabling us
to test high-level components like App without worrying about mocking
out all the imperative APIs (like fetch) that any downtree components
might need to use.

And even mount does not really work—it fails in some trivially basic
cases, which also happen to be cases that we’d want a lot in tests. In
particular, directly mounting a provider does not work
(enzymejs/enzyme#1751). This does not seem to
be a good tradeoff.

An alternative is to pass down the assets directly whitherever they
are required—the same semantics as context, but explicit rather than
implicit. This may sound onerous, but I don’t expect it to be: we
already do it for localStore, and that hasn’t proved problematic as
far as I know. This also saves all of the headache with testing,
because you just have another prop.

Integrating this into the router is only slightly weird, and
(importantly) is self-contained: we won’t have to think about it as we
add or change routes.

So, I effected this redesign, and it’s working great. In hindsight, it
certainly feels like the “right thing” to do. Only relevant changes were
made to tests, as opposed to needing to fix up everything under the sun,
which is a good sign. And it’s always nice to be explicit rather than
implicit.

We may in the future want to move back to a context-based system, if
it’s determined that (a) our testing infrastructure supports it and
(b) manual threading is really annoying for some reason. In such a case,
we should feel free to do so.