vhmth/gist:da7c26263d3dc29b3276

## gistfile1.html
<!DOCTYPE html>
<html>
    <head>
        <title>Vinay - Maker</title>
        <link rel="shortcut icon" href="/static/favicon.ico">
        <link rel="stylesheet" href="/static/css/styles.css">
    </head>
    <body class="blog-post">
        <h3 class="blog-title">Ember.js Fixtures</h3>
        <p class="date">Dated December 17th, 2013</p>

        <p>If you are using <a target="_blank" href="http://emberjs.com">Ember</a> as your client-side web framework, I may just save you a <em>lot</em> of trouble. Ember is still being heavily developed, so I never expected it to work perfectly out of the box, but today's ordeal with setting up fixtures (using <a target="_blank" href="https://github.com/emberjs/data">Ember Data</a>) was impressively hair-pulling. I will be fair and preface that most of these issues arose from Ember Data itself and not Ember, but I don't consider that a valid excuse.</p>

        <p>These were the main points that fucked me today:</p>

        <p><strong>1.</strong> Not much documentation.</p>
        <p><strong>2.</strong> Data store adapters handle data differently.</p>

        <p>I'll walk you through a few of the pitfalls I faced:</p>

        <p><strong>FML #1</strong> If you are using <a target="_blank" href="http://requirejs.org/">RequireJS</a> because you're sane, don't want to deal with dependency issues while modularizing your code, and overall think not polluting the global namespace is a good thing, then this will screw you over (all code in Coffeescript):</p>

<pre>
DS.Model.extend
    SOME_ARRAY_OF_OTHER_THINGS: DS.attr 'App.SOME_MODEL'
</pre>

        <p>The reason this screws you is because, if App is not available in the global namespace, Ember will not be able to look up "App.SOME_MODEL". This is an important nuance that I have yet to find documented <em>anywhere</em>. If it is, it's incredibly hard to find. Instead, set the model on your app instance and do this:</p>

<pre>
DS.Model.extend
    SOME_ARRAY_OF_OTHER_THINGS: DS.attr 'someModelInCamelCase'
</pre>

        <p><strong>FML #2</strong> If you have embedded models of any sort in your fixtures, <em>you are fucked</em>. That is, you must follow the following model of structuring your data:</p>

<pre>
App.MODEL.FIXTURES = [{
    OTHER_MODELS: ['1', '2', '3', ...],
    // ... other properties
}, ...]

App.OTHER_MODEL.FIXTURES = [{
    id: '1',
    // ... other properties
}, ...]
</pre>

        <p>You might be wondering what I'm talking about at this point. What I mean, is that I figured I would be able to do this:</p>

<pre>
App.MODEL.FIXTURES = [{
    OTHER_MODELS: [{
        id: '1',
        // ... other properties of this other model
    }, ...],
    // ... other properties
}, ...]
</pre>

        <p>I basically tried everything to make the latter work, and it didn't. My advice is to just manually set all fixtures as I have laid out in the former. If you dig on the interwebz, you will find <a target="_blank" href="http://stackoverflow.com/questions/13538409/ember-data-fixtureadapter-with-embedded-hasmany">this StackOverflow question</a> which has an answer that includes a "hasManyEmbedded" shim. This shim does not work with the latest stable (lol stable) Ember Data. Trust me. I wasted my time trying. You see the other answer that says you can get it working by creating explicit maps on the App's serializer? Yeah that doesn't work either.</p>

        <p><strong>FML #3</strong> You see how in my previous examples I made the Ids of the fixture models Strings? That wasn't by chance. Apparently, <a target="_blank" href="http://stackoverflow.com/questions/13296022/my-computed-values-stopped-working-with-latest-version-of-ember-data-js">the REST Adapter will normalize Ids to strings, but the Fixture Adapter won't</a>. Yay inconsitencies! Did you click on that link and see the answer on the StackOveflow question? You see how there's a link of the "breaking changes" that's supposed to list the breaking issues for revision 6 of Ember Data? That file doesn't exist in their git tree anymore. The gist is to make sure you make all your Ids in your fixtures Strings. Because God knows the Fixture Adapter won't. Then your shit will break.</p>

        <p>All the bitching aside, working with Ember has been pretty cool so far. I also have a lot of respect for Tom Dale based on his interwebz ramblings (besides <a target="_blank" href="http://tomdale.net/2012/01/amd-is-not-the-answer">this post</a>; Tom, if you are reading this, take a look at <a target="_blank" href="http://requirejs.org/docs/optimization.html">the r.js optimizer</a>). Most importantly, hopefully I saved y'all some time if you're getting started with Ember and need to get Fixtures working properly.</p>
    </body>
</html>
	<!DOCTYPE html>
	<html>
	<head>
	<title>Vinay - Maker</title>
	<link rel="shortcut icon" href="/static/favicon.ico">
	<link rel="stylesheet" href="/static/css/styles.css">
	</head>
	<body class="blog-post">
	<h3 class="blog-title">Ember.js Fixtures</h3>
	<p class="date">Dated December 17th, 2013</p>

	<p>If you are using <a target="_blank" href="http://emberjs.com">Ember</a> as your client-side web framework, I may just save you a <em>lot</em> of trouble. Ember is still being heavily developed, so I never expected it to work perfectly out of the box, but today's ordeal with setting up fixtures (using <a target="_blank" href="https://github.com/emberjs/data">Ember Data</a>) was impressively hair-pulling. I will be fair and preface that most of these issues arose from Ember Data itself and not Ember, but I don't consider that a valid excuse.</p>

	<p>These were the main points that fucked me today:</p>

	<p><strong>1.</strong> Not much documentation.</p>
	<p><strong>2.</strong> Data store adapters handle data differently.</p>

	<p>I'll walk you through a few of the pitfalls I faced:</p>

	<p><strong>FML #1</strong> If you are using <a target="_blank" href="http://requirejs.org/">RequireJS</a> because you're sane, don't want to deal with dependency issues while modularizing your code, and overall think not polluting the global namespace is a good thing, then this will screw you over (all code in Coffeescript):</p>

	<pre>
	DS.Model.extend
	SOME_ARRAY_OF_OTHER_THINGS: DS.attr 'App.SOME_MODEL'
	</pre>

	<p>The reason this screws you is because, if App is not available in the global namespace, Ember will not be able to look up "App.SOME_MODEL". This is an important nuance that I have yet to find documented <em>anywhere</em>. If it is, it's incredibly hard to find. Instead, set the model on your app instance and do this:</p>

	<pre>
	DS.Model.extend
	SOME_ARRAY_OF_OTHER_THINGS: DS.attr 'someModelInCamelCase'
	</pre>

	<p><strong>FML #2</strong> If you have embedded models of any sort in your fixtures, <em>you are fucked</em>. That is, you must follow the following model of structuring your data:</p>

	<pre>
	App.MODEL.FIXTURES = [{
	OTHER_MODELS: ['1', '2', '3', ...],
	// ... other properties
	}, ...]

	App.OTHER_MODEL.FIXTURES = [{
	id: '1',
	// ... other properties
	}, ...]
	</pre>

	<p>You might be wondering what I'm talking about at this point. What I mean, is that I figured I would be able to do this:</p>

	<pre>
	App.MODEL.FIXTURES = [{
	OTHER_MODELS: [{
	id: '1',
	// ... other properties of this other model
	}, ...],
	// ... other properties
	}, ...]
	</pre>

	<p>I basically tried everything to make the latter work, and it didn't. My advice is to just manually set all fixtures as I have laid out in the former. If you dig on the interwebz, you will find <a target="_blank" href="http://stackoverflow.com/questions/13538409/ember-data-fixtureadapter-with-embedded-hasmany">this StackOverflow question</a> which has an answer that includes a "hasManyEmbedded" shim. This shim does not work with the latest stable (lol stable) Ember Data. Trust me. I wasted my time trying. You see the other answer that says you can get it working by creating explicit maps on the App's serializer? Yeah that doesn't work either.</p>

	<p><strong>FML #3</strong> You see how in my previous examples I made the Ids of the fixture models Strings? That wasn't by chance. Apparently, <a target="_blank" href="http://stackoverflow.com/questions/13296022/my-computed-values-stopped-working-with-latest-version-of-ember-data-js">the REST Adapter will normalize Ids to strings, but the Fixture Adapter won't</a>. Yay inconsitencies! Did you click on that link and see the answer on the StackOveflow question? You see how there's a link of the "breaking changes" that's supposed to list the breaking issues for revision 6 of Ember Data? That file doesn't exist in their git tree anymore. The gist is to make sure you make all your Ids in your fixtures Strings. Because God knows the Fixture Adapter won't. Then your shit will break.</p>

	<p>All the bitching aside, working with Ember has been pretty cool so far. I also have a lot of respect for Tom Dale based on his interwebz ramblings (besides <a target="_blank" href="http://tomdale.net/2012/01/amd-is-not-the-answer">this post</a>; Tom, if you are reading this, take a look at <a target="_blank" href="http://requirejs.org/docs/optimization.html">the r.js optimizer</a>). Most importantly, hopefully I saved y'all some time if you're getting started with Ember and need to get Fixtures working properly.</p>
	</body>
	</html>