feat(#249): Adds default geopoint question type #300
Conversation
|
| this.rows = Number(element.getAttribute('rows')); // ToDo: Make parser function, validate NaN | ||
| this.accuracyThreshold = Number(element.getAttribute('accuracyThreshold')); // ToDo: Make parser function, validate NaN | ||
| this.unacceptableAccuracyThreshold = Number(element.getAttribute('unacceptableAccuracyThreshold')); // ToDo: Make parser function, validate NaN |
There was a problem hiding this comment.
Not suggesting a change this early on. Just adding a minor "yes and" on these TODO comments for additional context. There are two gaps here, and they apply in a few other places too:
accuracyThresholdandunacceptableAccuracyThresholdare specified as decimals. We'll want to make sure that whatever parsing we do accounts for that (including potential float rounding errors).rowsdoesn't specify its type explicitly, but I think it's safe to assume it should be an integer. Same thing about parsing the type, different type to account for.
I wish we'd been tracking these cases sooner, because like I said there are others!
WIP
Closes #249
I have verified this PR works in these browsers (latest versions):
What else has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Do we need any specific form for testing your changes? If so, please attach one.
What's changed