search

vocdoni / vocdoni-sdk

Vocdoni SDK for API
GNU Affero General Public License v3.0
13 stars 6 forks source link

feature: standarize election return for all methods returning elections #391

Closed elboletaire closed 4 months ago

elboletaire commented 4 months ago

Describe the feature

Right now, the InvalidElection can only be returned by the fetchElections (plural) method. I'd like that any method that can return an election (usually PublishedElection or ArchivedElection), handles invalid elections returning an InvalidElection instance, rather than crashing as they do now (like with fetchElection [singular]).

Motivation

The real motivation is the new explorer, where we'd like to show the election view for invalid elections as well as for valid ones, allowing users and developers to access the raw data button that's in such view.

In the explorer @selankon is working to manage this on our own, but it's something I've pending for the ui-scaffold, so other projects could benefit from it too.

You have an invalid election currently in stg, in case you want to have one by hand: https://vocdoni-explorer-stg.netlify.app/process/b31dff61814d0e39f9b3bf2b71bc37a8bb312f6c4d8965f1406f030800000000

Proposal

I'm not sure how the "raw" data is managed in InvalidElections, but checking the code it seems to me thy only accept an id. I'd recommend adding some way to put the raw data in there for an advanced analysis of the election object.

Components affected

Any currently returning elections but crashing for invalid ones rather than returning a InvalidElection instance.

selankon commented 4 months ago

At this moment is not possible to fix it in anyway on the explorer because the fetch election method throw an exception, making it impossible to instantiate an InvalidElection.

elboletaire commented 4 months ago

At this moment is not possible to fix it in anyway on the explorer because the fetch election method throw an exception, making it impossible to instantiate an InvalidElection.

That's true. And it made me think...

An intermediate implementation to not break backwards compatibility would be to throw the InvalidElection somehow (this way old implementations would still crash, and anyone wanting to grab that InvalidElection could do so via the catch of the throwing method).