#Ember Recipes
- Having tested recipes helps make ensure they still work with new versions of Ember.
- It helps document how you should test a feature in your app.
- It would enable us (or someone else) to build walk through test-driven tutorials for common Ember patterns and needs.
I do this with my add-ons as well, Edward Faulkner released an amazing ember addon called ember-cli-code-snippet that let’s you wrap anything in comments that can later be embedded as documentation. This will help to ensure that the code shown on screen in the overview is always the current code for the ember-twiddle too.
One of the things missing from Ember’s guides are how all the concepts actually fit together. Wherever possible, the purposes for which various primitives exist should be clearly discussed.
A recipe should never be based on a private API or a “hack”, even if it is a commonly seen pattern (routing has many of these).
For recipes (such as history management) for which there aren’t clean APIs already, recipes should be put into a special Advanced category and clearly marked as at risk.
A document outlining the process for suggesting an improved public API to Ember for areas where a feature requires use of private APIs, undocumented APIs/behaviors, or hacks should probably be produced and linked to.
Their blog post would receive an attribution link, their blog post should be updated with a recipe badge at the top of the post. This badge would also include the text beside it that says something along the lines of This post was current as of Ember 1.11.1, but an updated tutorial can be downloaded as a recipe by clicking the recipe badge to the left.
By testing the recipes, we may be able to use ember-try to automate at least part of keeping the version range accurate.
Recipes with deprecations should have their version range capped at the last version without a deprecation until those deprecations are handled.
Enough said there. Ember-watson might be able to help us on this front.
Point blank, I’m tired of hearing it’s hard to learn Ember. Let’s change that. I’m willing to put a lot of time into the design and UX of the recipe website.
Recipes should be coded such that they can be used together in any manner. This both lets a user browsing them drop them into their site if needed, and let’s us use the recipes within the app to build the app or an example app that’s a better representation of ember than todo-mvc.