成员Cli幻影:使用JSONAPISerializer的活动模型适配器

Question

我正在实现JSON API结构的一半(带有下划线属性)。

开发环境的实际状态是

我使用主动模型适配器结构向后端请求资源，并使用JSON API结构对后端进行响应。

在应用程序序列化程序中，我使用JSONAPISerializer。我重写方法：

serializeBelongsTo
keyForRelationship
keyForAttribute
serialize
serializeAttribute
serializeHasMany

对于开发，一切都适合我( Rails的后端与Ember进行了很好的通信)。

问题与Ember幻影和约定有关(不确定是否有简单的解决方案，或者我需要再次重写这个插件中的方法)。

实际状态与Ember Cli幻影和测试环境：

我使用import { JSONAPISerializer } from 'ember-cli-mirage';，然后尝试操作正确的请求，然后将其转换为JSON格式。

它可以这样工作：

成员适配器(活动模型适配器格式-带有下划线属性)-幻影序列化程序应该得到请求(在使用关联的测试中

现在，我缺少一个部分来序列化所有情况下的JSON标准(带有突出显示的属性)。

我应该在哪里进行此转换以最小化重写的JSONAPISerializer幻影序列化程序。

我注意到有一些帮手，但是我很难把这些知识整合在一起(http://www.ember-cli-mirage.com/docs/advanced/route-handlers#helpers)

更新：

后端的结构示例：

{
  "data": {
    "id": "6",
    "type": "first_resource",
    "attributes": {
      "id": 6,
      "my_attribute": "my_attribute"
    },
    "relationships": {
      "second_resources": {
        "data": [
          {
            "id": "16",
            "type": "second_resource"
          }
        ]
      },
      "third_resource_other_type": {
        "data": {
          "id": "1",
          "type": "third_resource"
        }
      },
      "fourth_resource": {
        "data": {
          "id": "1",
          "type": "fourth_resource"
        }
      }
    },
    "links": {
      "fifth_resources": "/api/v1/first_resources/6/fifth_resources"
    }
  },
  "included": [
    {
      "id": "1",
      "type": "fourth_resource",
      "attributes": {
        "id": 1,
        "my_attribute": "my_attribute"
      },
      "links": {
        "sixth_resource": "/api/v1/fourth_resources/1/sixth_resource"
      }
    },
    {
      "id": "16",
      "type": "second_resource",
      "attributes": {
        "id": 16,
        "my_attribute": "my_attribute"
      },
      "relationships": {
        "eighth_resources": {
          "data": []
        }
      },
      "links": {
        "seventh_resources": "/api/v1/second_resources/16/seventh_resources"
      }
    },
    {
      "id": "17",
      "type": "second_resource",
      "attributes": {
        "id": 17,
        "my_attribute": "my_attribute"
      },
      "relationships": {
        "eighth_resources": {
          "data": []
        }
      },
      "links": {
        "seventh_resources": "/api/v1/second_resources/17/seventh_resources"
      }
    },
    {
      "id": "15",
      "type": "second_resource",
      "attributes": {
        "id": 15,
        "my_attribute": "my_attribute"
      },
      "relationships": {
        "eighth_resources": {
          "data": [
            {
              "id": "26",
              "type": "eighth_resource"
            },
            {
              "id": "24",
              "type": "eighth_resource"
            }
          ]
        }
      },
      "links": {
        "seventh_resources": "/api/v1/second_resources/15/seventh_resources"
      }
    },
    {
      "id": "26",
      "type": "eighth_resource",
      "attributes": {
        "id": 26,
        "my_attribute": "my_attribute"
      }
    }
  ]
}

UPDATE2

海市蜃楼结构反应：

data: {
  attributes: {
    my_attribute: 'my_attribute',
    second_resource_ids: [36, 37],
    fifth_resource_ids: []
  },
  id: 11,
  relationships: {
    third_resource_other_type: {data: null}
    fourth_resource: {data: null}
    second_resources: {data: []}
  },
  type: "first_resources"
}

测试资源：

server.create('second-resource', {
  id: 36,
  first_resource_id: '11',
  my_attribute: "my_attribute"
});

server.create('eighth-resource', { 
  id: 140,
  second_resource_id: 37
});

server.create('eighth-resource', {
  id: 141,
  second_resource_id: 37
});

server.create('second-resource', {
  id: 37,
  first_resource_id: '11',
  eighth_resource_ids: [140, 141]
});

server.create('first-resource', {
  id: 11,
  second_resource_ids: [36, 37]
});

海市蜃楼中的first_resource模型：

export default Model.extend({
  third_resource_other_type: belongsTo(),
  fourth_resource: belongsTo(),
  fifth_resources: hasMany(),
  second_resources: hasMany()
});

Answer 1

让我们试着把注意力集中在一个单一的关系上，因为在你发布的问题中有很多事情发生了。我们来看看second-resource。

看起来，幻影正在JSON:API有效载荷中的second_resource_ids主数据的attributes键下发送回first_resource。这告诉我，幻影认为second_resource_ids是first_resource的一个属性，而实际上它是一种关系。

假设您的模型和关系设置正确，您需要调整在幻影中创建数据的方式。

如果您查看一下定义路线指南中的关联部分，您将看到以下消息：

幻影的数据库对所有模型属性都使用camelCase，包括外键(例如上面示例中的authorId )。

现在，你要这么做：

server.create('second-resource', {
  id: 36,
  first_resource_id: '11',
  my_attribute: "my_attribute"
});

server.create('first-resource', {
  id: 11,
  second_resource_ids: [36, 37]
});

但是从幻影的角度来看，您需要使用camelCase in，或者只是传递关系，才能正确地设置这些in。就像这样：

let firstResource = server.create('first-resource', {
  id: 11
});

server.create('second-resource', {
  id: 36,
  firstResource,
  myAttribute: "my_attribute"
});

如果需要，还可以在创建时传入外键--只需确保使用camelCase：

server.create('second-resource', {
  id: 36,
  firstResourceId: '11',
  myAttribute: "my_attribute"
});

请记住，属性和外键(比如some-attribute与some_attribute或relationship-id与relationship_id)的格式化决策是在序列化层做出的。在处理幻影的ORM和数据库时，您希望坚持使用camelCase，而不管序列化程序发射的格式如何。

有关更多信息，请从文档中查看这些部分：

• Quickstart的“关联和序列化器”部分
• 定义关系
• 工厂指南“与关系一起工作”一节