Only use legal characters in query config name

[taion]

Fixes #196

[denvned]

Don't we still need an unique query config name for a given set of queries, because getRelayQueries uses it as a part of the cache key? Otherwise Relay would probably use the set of queries belonging to the old route after changing the route to a new one (in the case the query params stay the same).

[taion]

Ugh yes. Hmm.

[nodkz]

So maybe remove $$_ and give other prefix:
Eg.

['react-router-relay', ...Object.keys(queryConfig.queries)].join('-');

[taion]

@denvned I'm afraid of collisions though. What do you think of 2cb9d20?

[denvned]

Maybe generate query config names sequentially and save them in a map where the key is String(Object.keys(queryConfig.queries))?

[taion]

I'm a little bit worried about non-determinism there. It means that the query names will end up being different depending on order of rendering. Wonder if this might lead to odd server/client mismatches.

[denvned]

You mean isomorphic rendering? E.g. if some app for some reason renders a query config name in a React component? Then yes, it might cause a markup mismatch.

The other alternative I can propose is just to encode the name using hex or base62.

[taion]

That's what I'm doing with generateRQLFieldAlias, though. Are you concerned about the Relay-internal API usage?

[denvned]

I'd prefer to avoid Relay internals, but I'm more concerned about that generateRQLFieldAlias encodes the hash of a name, not the name itself, and that can cause collisions, although the probability is very low.

[taion]

Okay, let's go with that: 2c4cbdf

@johntran Can you check if this code works?

[denvned]

👍 for meaningful query config names, but I would use __ (double _) to join query names to avoid some collisions, e.g. between [foo_bar, baz] and [foo, bar_baz]. Maybe I would even check that a query name doesn't contain __ (double _), and doesn't start or end with _, to completely avoid collisions. Checking that query names consist of only /[_a-zA-Z0-9]/ would be also useful for catching user errors early.

[taion]

They do have double underscores, because I join with _ and also start the generated query names with _.

I'd rather not do extra validation on user query names. I feel like it's rather unlikely to come up. I still don't have a repro for the reported issue here, even.

[johntran]

@taion The latest updates work with both default and custom network layers.

[taion]

v0.13.5