-
-
Notifications
You must be signed in to change notification settings - Fork 517
Add Ember Data flexibility
section
#240
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding the new section makes sense. My only criticism is the ambiguity of the statement: "This will allow your code to evolve without becoming a mess." I think something that explains the nature of the "mess" would be better: "This will allow your code to evolve while encapsulating data retrieval and maintaining complex relationships between various data objects."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple wording tweaks. Thanks for writing this! I think it is helpful context.
Co-Authored-By: ppcano <pepe@loadimpact.com>
Co-Authored-By: ppcano <pepe@loadimpact.com>
@jenweber Thanks for reviewing it. The requested changes are done. What are the thoughts about?
I commented previously on this discussion that I think it could be a good idea if the the docs promotes more the "Flexibility" of Ember Data and a "little less" the benefits of using If there is an community agreement on this suggestion, I can try to tweak the content with small PRs. |
@ppcano I like both of these ideas. Want to give a rough draft a try and PR it? We can also run some questions by the Ember Data team to get their vision on these points. Also, we have been kinda moving away from the "Convention over configuration" type language because it doesn't really seem to resonate anymore, so maybe you could help improve that too. The JSONAPI section was probably written when the project was brand-new. I have a feeling that we can keep the same content level with fewer words, now that the project is better established and known. |
* Add `Ember Data flexibility` section * Update guides/v3.5.0/models/index.md Co-Authored-By: ppcano <pepe@loadimpact.com> * Update guides/v3.5.0/models/index.md Co-Authored-By: ppcano <pepe@loadimpact.com>
* Add `Ember Data flexibility` section * Update guides/v3.5.0/models/index.md Co-Authored-By: ppcano <pepe@loadimpact.com> * Update guides/v3.5.0/models/index.md Co-Authored-By: ppcano <pepe@loadimpact.com>
The change splits the section
What are Ember Data models?
in two parts:What are Ember Data models?
Ember Data flexibility
I described the reasons for this change on the
When to add Ember Data
discussion.This made me think how the documentation of the default format of Ember Data is communicated or may be interpreted.
@jenweber suggested creating small incremental PRs, so this is a small change to highlight more the existing content around the "Flexibility" capabilities that was included in the
What are Ember Data models?
.Additionally, I also thought about:
extend a little more the
Ember Data flexibility
section.Tweak the content of the
Convention Over Configuration with JSON API
section.But I didn't want to include more changes without validating if there is a shared opinion on the topic.
Relates to #20