Route specificity doesn't match my expecations

[tivac]

(see my SO question for the original issue & recommendation that I file a bug)

I've been using falcor to experiment and have found a router behavior I didn't expect. My routes look something like the following:

1. items[{integers:ids}].name
2. items[{integers:ids}][{keys:fields}]

No matter the order I declare the routes in if I make a request to the router for items.0.name it'll always be handled by route 2 (the more generic one). It seems like [{keys}] should be lower specificity than a specific field, or even multiple fields. Are the specificity rules laid out somewhere in the docs? I couldn't find them.

Currently I'm getting around this by structuring my routes like this:

• items[{integers:ids}].name
• items[{integers:ids}]['fooga', 'wooga', 'booga', 'tooga', ... ]

Which is super-brittle if new fields become available and also really ugly to write. It also can't be aliased so instead of the really nice pathSet.fields I have to iterate on pathSet[2] which makes for less obvious code.

[tivac]

I've been able to mitigate this now that I understand falcor better by wrapping my objects I need to return as atoms, most of them are small enough that I don't really need specific keys queried out.

This still seems like broken behavior though.

[bobvanluijt]

I'm having the same issue, any updates here?

[tivac]

@michaelbpaulson Awesome, thank you!

[bobvanluijt]

thx