Skip to content
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

Introduce alternate syntax for in-line fragments #16

Open
slindberg opened this issue May 22, 2014 · 1 comment
Open

Introduce alternate syntax for in-line fragments #16

slindberg opened this issue May 22, 2014 · 1 comment
Labels
discuss enhancement Used when the PR adds a new feature or enhancement.

Comments

@slindberg
Copy link
Contributor

Fragments are designed to be reusable and flexible, but that comes at the cost of a verbose API. For the simplest use cases, it should not be necessary to declare a new DS.ModelFragment class. This could be possible by introducing some sugar on top of the current API, which would allow for reuse/flexibility when needed.

@silvinci's proposed a concise shorthand syntax in his comment on the epic thread that started this all:

App.Customer = DS.Model.extend({
  // Shorthand for `DS.hasOneFragment`
  name: DS.obj({
    first: DS.attr("string"),
    last: DS.attr("string")
  }),

  // Shorthand for `DS.hasManyFragments`
  invoices: DS.arr({
    sum: DS.attr("number"),
    items: DS.hasMany("items")
  }),

  // Shorthand for `DS.hasManyFragments` that accepts 'primitive' type
  loginDates: DS.arr("date")
});

It should be trivial to auto-generate anonymous DS.ModelFragment sub classes in the DS.obj and DS.arr property helpers, however this syntax raises a few issues:

  1. These fragments could not be created through DS.Store#createFragment, which means they would need to be created via literals proposed in Allow fragment attribute setters to accept object/array literals #10 (or DS.FragmentArray#createFragment).
  2. What serializers do anonymous fragments use? I doubt it is acceptable to be locked into using DS.JSONSerializer. Perhaps a default fragment serializer can be introduced that can be overridden in the container? Naming the generated fragment using a combination of the model type and attribute name seems wrong.
  3. DS.arr and DS.hasManyFragments cannot be used interchangeably since passing a string to DS.arr would introduce ambiguity, e.g. is the string an attribute type or a fragment type? This may be a good thing.

The idea of anonymous model classes is a dubious one, however I cannot readily point to why. Another downside to this syntax is that it's not immediately obvious from the naming what the expanded form is, e.g. obj doesn't have readily apparent connection to hasOneFragment.

@knownasilya
Copy link
Collaborator

knownasilya commented Nov 16, 2020

Yes please. Also why not allow using createFragment? Just add an id property

invoices: DS.arr('invoice', {
    sum: DS.attr("number"),
    items: DS.hasMany("items")
  }),

Then you can use createFragment('invoice'...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss enhancement Used when the PR adds a new feature or enhancement.
Projects
None yet
Development

No branches or pull requests

2 participants