How to define fragment dynamically?

[gauravjain028]

I want to use params as dynamic fragment, so i have created it as computed property. But it is not working. I have used like

import Ember from 'ember';
import DS from 'ember-data';

import {
	fragment
} from 'model-fragments/attributes';

export default DS.Model.extend({
	title: DS.attr('string'),
	type: DS.attr('string'),
	rows: DS.hasMany('row'),

	params: Ember.computed('type', function(){ 
		return fragment(this.get('type')); 
	})
});

But this give me error:

ember.debug.js:6778 Uncaught Error: Assertion Failed: Ember.Object.create no longer supports defining computed properties. Define computed properties using extend() or reopen() before calling create().

[workmanw]

@gauravjain028 I'm sorry, but I don't think this is something we can support in this manner. There is a lot of additional setup that goes on behind the scenes to make this app work, not unlike belongsTo and hasMany. I think you might try a polymorphic solution: https://github.com/lytics/ember-data-model-fragments#polymorphism

[bgerami]

this is what i'm doing

// models/user.js
import Ember from 'ember';
import DS from 'ember-data';
import { fragment } from 'model-fragments/attributes';

export default DS.Model.extend({
    project: DS.belongsTo('project', {inverse: 'user'}),
    data: fragment('data', { defaultValue() { return {}; }}),
    fixupDataAttrs: Ember.observer('project.keys.@each.label', function () {
        var attrs = {};
        this.get('project.keys').forEach(function (key) {
            attrs[key.get('label')] = DS.attr(key.get('type'));
        })
        this.get('data').reopen(attrs);
    })
})

However, my needs are different. My models must be generated lazily from a schema we grab from an XHR payload. They also can be backwards compatible.
I'm also not entirely sure what issues might come from this method. Thoughts?

[workmanw]

@bgerami that's an interesting approach. I'd say if it works for you go for it. I will caution you that you may have to tweak this solution over time. Using the runtime [observer] to modify the declarative definition seems like it could be a little brittle, say if ember-data chooses to restructure their internals. But a clever solution nonetheless.

@gauravjain028 I'm going to close this issue because I believe two solutions have been offered here. If you think there is a bug here, or want to further discuss this, please reopen it.