-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🛤️ tracking: Rewrite Guides for EmberData #8394
Comments
Is anyone working on it? If not I would like to contribute. |
@Aryan1982 would love help! sorry, the notification here got buried in my inbox <3 |
I would like to contribute to this ? |
@VedanthB awesome! I think starting with the items in section 1 would be best. I began this work already (you can see the READMEs below) which could give you a good sense of the starting point, though even these READMEs should be reviewed and improved |
I would like to work on the guides, since I am new to open source could you suggest smaller packages that I can start with? @runspired |
@thevinitgupta I think either the I gave a bit of an architectural overview of the request management story here: https://discord.com/channels/480462759797063690/480501977931972608/1152722044002254929 |
I'd would love to work on the guide. Do you still need help? |
EmberData has changed, and as we prepare for the Polaris edition a key milestone will be generating updated documentation to show modern usage.
The library as shown by the current guides at
guides.emberjs.com
, the code examples throughout the docs atapi.emberjs.com
, and the usage as shown in the tutorial app in the guide fall short of covering many key topics and no longer map to the recommended path.This quest exists to assist us on the course of writing new guides, new tutorials, and in improving the api docs. For this quest, we want to focus on documentation that exists in four locations:
1. README's of the EmberData packages should contain an approachable learning story for the respective package, with appropriate linking to further reading on other packages and deeper subjects.
2. Each package referenced in the API Documentation should have its own overview
This overview should mirror the content of the README by explaining what the package is for, when you might use it, how it fits into EmberData overall, and how to use its primary APIs.
3. API Documentation should be upgraded to ensure modern usage examples and to ensure that new users are steered towards recommended patterns at all times within the docs.
We should pay especial close attention to the documentation for the
Store
, and to ensuring that documentation forAdapter
andSerializer
make it clear that these are specific implementations of now legacy concepts, and steer folks to using new recommended patterns.For
Model
we will want to similarly make it clear that@ember-data/model
is an implementation of a presentation class for resources. It will remain the recommended approach for such until the library offers a new default solution (coming in 5.x).4. Markdown files placed in
<project>/guides/src/
should be written to replace and enhance the current guides content. (We are going to consider rewriting the Ember tutorial app out of the scope of this particular quest, but would be overjoyed for someone to take that effort on).This learning story should teach EmberData "from the
fetch
up", the most basic usage being to use@ember-data/request
for "just fetch". From fetch users learn about the difference between resources and documents and adding caching for them by installing@ember-data/store
and configuring aCache
to match their API format (graphql
,trpc
json:api
rest
etc.). Finally, users learn about usinginstantiateRecord
to hydrate data from the cache into rich presentational classes.Guides Pages
Fundamentals (these are designed as stand-alone articles, but ordered to build understanding from the ground up)
Tutorials
Advanced
Known Problem Areas
These are areas that others have requested documentation improvements in that may or may-not be covered by the above, we should be sure to ensure they also exist.
From @anlumo in #5756
DS.Model.eachRelationship
andDS.Model.eachAttribute
.DS.belongsTo
andDS.hasMany
being async by default.unloadRecord
.defaultValue
instead ofnull
.The text was updated successfully, but these errors were encountered: