You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few discrepancies between names for data structures on the front end vs. back end. While this can be worked around, it would be more efficient to simply have consistent naming between the front end and back end (not counting the camel case vs. snake case difference for JS vs. Ruby).
The discrepancies are:
"Attempt" on the front end vs. "User puzzle attempt" on the back end. This should likely be "user puzzle attempt" in both places, although it can still be displayed as simply "attempt" on the front end. But the term "attempt" by itself is a little too vague in the context of state slices, DB tables, etc.
"type data" on the front end vs "panel subtype" on the back end. This discrepancy was born of the slightly unintuitive way that Rails handles polymorphic associations, resulting in awkward phrases like "panel subtype type" and "panel subtype ID," which I tried to avoid on the front end by calling the object "type data" instead. It's possible that the "panel subtype" association should really just be called something else that results in more intuitive names for the polymorphic association fields so that a single name can be used consistently between the back end and front end. It's also possible that there shouldn't be a polymorphic field here at all, but that hint panels should simply have a letterPanelId, searchPanelId, etc. for each hint panel type, and that all of them except for one should be null for any given hint panel. This also seems awkward, though.
The text was updated successfully, but these errors were encountered:
apmwebdev
added
the
refactor
Changing the way the code is written without changing (much of) the functionality
label
Oct 1, 2023
There are a few discrepancies between names for data structures on the front end vs. back end. While this can be worked around, it would be more efficient to simply have consistent naming between the front end and back end (not counting the camel case vs. snake case difference for JS vs. Ruby).
The discrepancies are:
letterPanelId
,searchPanelId
, etc. for each hint panel type, and that all of them except for one should be null for any given hint panel. This also seems awkward, though.The text was updated successfully, but these errors were encountered: