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

[Ember] 1on1 request: components & actions & structuring code in app #305

rhjones opened this issue Nov 7, 2016 · 2 comments


Copy link

rhjones commented Nov 7, 2016

I have two components that I'm reusing throughout my app, in other components and in different routes. For example: a "favorite this!" button that's visible at /patterns, at /patterns/:pattern_id (the pattern route), when viewing an individual project based on that pattern (at /projects/:project_id), when viewing the user's list of favorites (favorites), and in other places.

I'm starting to repeat code for these components' actions across different routes (pattern, patterns, favorites, etc.), which seems less than ideal / prone to errors.

I'd like to meet with someone for a few minutes to a) double check my understanding of how actions work / are connected across components and routes; and b) see if there's a way to reduce some of the repetition I'm experiencing.

Copy link

@rhjones I'll meet with you in the morning. If I understand your use-case correctly, some duplication may be necessary. Maybe we can come up with some heuristics to record here after looking at your code.

@jrhorn424 jrhorn424 assigned jrhorn424 and unassigned jrhorn424 Nov 8, 2016
Copy link

After discussing some options, we decided to go with injecting the store into the component to do the CRUD on the favorites join. Arguments for doing it this way:

  1. The CRUD is linked to "toggling" a join property (favorite) with a primary property (pattern). The "toggling" happens by deleting a row or adding a row as appropriate to the favorites table.
  2. Because the component is re-used in approx. 4 routes across two different containing components, it felt more like a service concern (tempted to create a service), but since it was a service provided by an internal API that already had a front-end model, we opted to inject the store.
  3. It's possible there are better component architectures. The components seemed well-abstracted pieces of encapsulated UI.
  4. We did not explore closure actions

rhjones added a commit to rhjones/quiltr that referenced this issue Nov 8, 2016
Inject store into favorite button component
Instead of sending action, toggle favorite (add/delete favorite record) directly from component

Why this approach? After talking with @jrhorn, we decided this makes the most sense because:

- component is used in multiple other components & routes
- CRUD action involves adding/deleting a row from a join table
- See ga-wdi-boston/capstone-project#305 (comment) for full details
@rhjones rhjones closed this as completed Nov 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants