[Code health] Disambiguate `PhotoResponse` and `PhotoResult`
gino-m opened this issue · comments
Currently we have PhotoResponse in the model and PhotoResult in the view.
IMO, PhotoResponse in the model should be renamed to PhotoResult for consistency with GeometryTaskResult, and PhotoResult in the view should be renamed just Photo or PhotoData.
@scolsen WDYT?
sgtm!
@gino-m so, looking into this, it actually seems like GeometryTaskResult is the current outlier - we use Response for all other submission types in the model.
Should we rename all *Response to Result? and use Response in the view instead?
Note that we also currently use *Result for all of the types in the View.
Ultimately, it seems a tad unfortunate to me that we currently end up needing 3 types for each piece of submittable data we support:
- The model object itself for use in other parts of the app at runtime (e.g.
Geometry) - The "Result" object in the view
- The "Response" object in the model
It would be nice if we reduced this to two types, I think and eliminated the Result view objects entirely. I don't know yet whether that's feasible for all types.
I see, thanks for clarifying. Focusing on the model for a second, I intended Result and Response to be subtypes of Value inside SubmissionData. The idea was that questions have responses, and other tasks have results.
If we want to simplify that hierarchy, perhaps we stick with just Value? I like Result better as it's more specific, but it's not very idiomatic when applied to question tasks. Any thoughts?
The idea was that questions have responses, and other tasks have results.
Ah ok, that makes sense. Based on that, a few follow up ideas:
- I think we should move all response/result types into the same place. Right now, some are in the model (
NumberResponse,GeometryTaskResult) while others are in the ui package (DropPinTaskResult,DrawAreaTaskResult). We should move all of these into one package since this will help clarify their shared purpose. Furthermore, it might help clarify the distinction betweenResponse/Result - I agree that we should stick with one name, this is particularly well-motivated by the fact that they are all subtypes of
Value. While conceptually making a distinction between values retrieved from questions (responses) and values retrieved from active tasks (results) makes sense, it's not technically a distinction captured in our system—it would be a difference in naming convention alone, which I think is more prone to induce questions down the road. I think if we want to enforce a conceptual distinction like this within the application, this should have an encoding, probably as a type-level distinction (e.g. someValuesupertype and someResultsupertype). Right now though, there seems to be no technical reason we'd need this distinction, so I think we should just opt for a single name and treat it all as instances of the same class of problem (representing data submitted by the user). I'd be ok with using either*Valueor*Result. I do think*Resultimplies in every case that it's data coming from the user.Valueis a little more vague and could be coming from anywhere. Or we just get as specific as possible and useSubmissionData--GeometrySubmissionData,TextSubmissionData,DropPinSubmissionData
+1 on both accounts. In this context, SubmissionData refers to what was collected and submitted as part of the data collection process. In that could, can we just extend this to the concept of data for a specific task, perhaps TaskData? In that case we could have classes like MultipleChoiceQuestionTaskData, TextQuestionTaskData, CapureLocaitonTaskData, etc? It's a tad more verbose, but unambiguous. Wdyt?
Let's do it!