Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize data structure names between back end and front end #63

Open
apmwebdev opened this issue Oct 1, 2023 · 0 comments
Open
Assignees
Labels
refactor Changing the way the code is written without changing (much of) the functionality

Comments

@apmwebdev
Copy link
Owner

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.
@apmwebdev apmwebdev added the refactor Changing the way the code is written without changing (much of) the functionality label Oct 1, 2023
@apmwebdev apmwebdev self-assigned this Oct 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Changing the way the code is written without changing (much of) the functionality
Projects
None yet
Development

No branches or pull requests

1 participant