awslattery / ideafunding2019 Goto Github PK

Currently, the state of the application is to display the loading animation indefinitely, whereas there may be a failed response from the Cloud Firestore database that isn't properly being handled.

Resolution of this issue should:

• provide some form of user feedback that an error has occurred
• if the error is something that should be retried, ideally we would present a workflow (e.g. button) for a user to retry the failed request
• if the error is due to a Cloud Firestore read error, it should be considered that the application has been suspended, and display a "thanks for voting, see you next year" message.

As we'll have documentation for both the function(s) and the client directories, it'd be nice if our README reflected these additions and included a summary of the project.

As this started out as a side project used once a year, to something that could be beneficial for someone to stumble across, I'd like to add support for testing of the functional code, where it would make sense.

This issue would ideally cover these core taskings:

• choosing a testing framework, and implementing it as necessary via dependencies and scripting in the client and/or functions package.json
• include an update to the documentation to describe testing procedures
• an example test case for other contributors to follow

Currently, on both mobile and fullsize devices, a user cannot select the phone number displayed, due to a user-select property set higher up in the styled-component tree.

For users who wish to copy the number, but not auto-populate their vote (e.g. their version of iOS doesn't support the modern SMS intent), they should be able to:

• select the voting phone number, and interact with their native clipboard

This could be accomplished simply by adding user-select: text; to the VotingPhoneNumber styled component in client\src\components\Voting\Instructions\index.js.

Right now, we're lacking documentation across the board. This issue would be resolved by adding sufficient information pertaining to the client directory, including:

• overview of the language, tools, and frameworks utilized
• development environment setup instructions
• build instructions
• deployment instructions

Previously, this library relied on Nexmo's SMS API/webhooks, however, as they no longer offer free inbound SMS processing, we made the determination to switch to a more robust and popular provider, Twilio.

As we'd like for this repository to be a bit more versatile for other uses, it'd be beneficial to add support for other telephony platforms, such as Nexmo, Plivo, and others that are requested and have notable market share.

As part of implementing this feature, it should incorporate:

• a check against the poll settings in Cloud Firestore, which will include a parameter for defining which telephony provider is used (currently, the IdeaFunding 2019 poll is set to "twilio"); a mechanism by which to switch payload handling based on the defined provider
• the necessary additional code/refactoring to support Nexmo's webhook payloads

and, ideally, it should include:

• a test case for successful vote insertion
• a test case for a bad payload (e.g. missing param, malformed data, etc.)

As described in #12 , we're lacking documentation across the board. This issue would be resolved by adding sufficient information pertaining to the functions directory, including:

• overview of the language, tools, and frameworks utilized
• development environment setup instructions
• build instructions
• deployment instructions