Avoid doing default renders related to results

[elboletaire]

The title is a bit weird, but it's because we're using multiple default cases (in rendering switches) that can fail if we're not sure about the type of voting we're rendering. Here's an example:

https://explorer.vote/process/6b342d99f2187bf87ae56dfceaf3b6531c336365830e460e212d02000000006d/1

As you can see, the reuslts show like there's one vote for the first option. Now, if you check the Raw tab, you'll see the array of results is huge, and it's not being properly rendered.

This is because this type of voting is a "cumulative voting", something we didn't take into account when building our components. Since this is something can happen more often than we think, all the components that are rendering different based on the type of voting, should stop doing that. Not sure what's the best solution here... depending on the view we should do additional checks to hide some tabs (i.e. in processes we'll have to hide the results one, since we cannot render it).

This has to be reviewed process-wide, which includes other places like ui-components, where we may have some of these defaults.

[selankon]

After take a look to the election that breaks the explorer we found that on the metadata it appears that is a SINGLE_CHOICE_MULTIQUESTION when in reality is a Acumulative voting.

So we should try prevent non supported voting types without looking to the metadata. Things to do, for example, is check if the results array is bigger than the questions array (as sugested by @elboletaire).

Also, if something breaks just don't render anything or the raw content.

[elboletaire]

Also, if something breaks just don't render anything or the raw content.

This would be a great improvement overall.

[selankon]

check if the results array is bigger than the questions array

This is not a solution at all. On this election case, there was a 100 weight to use for each option, so the results array is 100 length for each choice.

So what happen if we have an election with 4 choices and 4 of weight? (ok, is an edge case but can be). We could create some kind of function that for each election metadata type do some checks to see if is what metadata say.

For the moment, lets fix the component to do not crash

[elboletaire]

So what happen if we have an election with 4 choices and 4 of weight? (ok, is an edge case but can be). We could create some kind of function that for each election metadata type do some checks to see if is what metadata say.

We may need to sum the results array, not just take its length. But this adds complexity and could still have edge cases.