Setup error screens

[beausmith]

Fixes #1041

This PR needs:

• backend data to enable screens.
• tests based upon mocked data.

Error Screens

These screens will display for all users if the state is such.

Low battery and no charger

Card Reader not detected

No Printer Detected

Printer Error Detected

Warnings on Insert Card Screen

These warnings are informational but non-blocking. They are visible to both Poll Workers and Voters.

Note: It is possible for both of these warnings to appear at the same time.

No Power Warning

No Accessible Controller Warning

[netlify]

Deploy preview for vw-bmd ready!

Built with commit 8d293b3

https://deploy-preview-1050--vw-bmd.netlify.com

[beausmith]

@eventualbuddha - I have added a Hardware API. This seemed simpler than separate APIs for each.

Open to all suggestions for any refactors, etc.

What else do you need from me to implement a "module-hardware" or whatever you think is best?

I'm adding tests now…

[beausmith]

@eventualbuddha - The last commit on this branch is a WIP with debugging code. I'm stumped as to why this is undefined. MemoryHardware is modeled after the MemoryCard, but something must be different. Do you see where the error in this code is?

[eventualbuddha]

Commented at the source of the problem. It’s an unbound method problem. I’d fix it by doing const { hardware } = this.props and calling i.e. await hardware.read….

[eventualbuddha]

This is the call that’s making this be undefined inside readAccesssibleControllerStatus. When you call a function without a context in strict mode you get this === undefined (in non-strict mode you get this === window).

For example:

const obj = { m() { return this } }
const { m } = obj
const mBound = ::obj.m // https://github.com/tc39/proposal-bind-operator

// These all pass.
assert(obj.m() === obj)
assert(m() === undefined)
assert(m.call(obj) === obj)
assert(mBound() === obj)

Note that the bind operator proposal is still stage 0 and won’t be implemented in TS until stage 3 at the earliest.

[eventualbuddha]

These set* methods don’t represent operations we can actually perform in non-test scenarios, i.e. the battery level is what it is. I’d say these should not be present on the Hardware interface but should be defined on MemoryHardware. Unless I’m missing something?

[eventualbuddha]

Commented at the source of the problem. It’s an unbound method problem. I’d fix it by doing const { hardware } = this.props and calling i.e. await hardware.read….

[beausmith]

@eventualbuddha - I've rebased, squashed, and pushed commits. Everything is working, however there are a couple regressions I've failed to figure out. I've got to hang my hat for the night. Back to this tomorrow.