Question

我正在实现JSON API结构（带有下划线属性）的中途。

开发环境的实际状态为：

我使用Active Model Adapter结构向后端请求资源，并且后端使用JSON API结构来回复我。

在Application Serializer中，我正在使用JSONAPISerializer。我重写方法：

serializeBelongsTo
keyForRelationship
keyForAttribute
serialize
serializeAttribute
serializeHasMany

对于开发而言，一切都对我有用（Rails的后端与Ember的交流非常好）。

问题与Ember CLI Mirage和约定有关（不确定是否有简单的解决方案，或者我是否需要再次覆盖此插件中的方法）。

Ember Cli Mirage和测试环境的实际状态：

我正在使用import { JSONAPISerializer } from 'ember-cli-mirage'; 然后尝试处理适当的请求，然后将其转换为JSON API格式。

它可以这样工作：

Ember适配器（活动模型适配器格式-具有下划线属性）---> Mirage序列化程序应获取请求（通过关联查找测试之前创建的资源），然后以JSON API格式进行响应---> JSON API序列化程序可以抓住它并填满Ember DS。

目前，我缺少将所有情况下的序列化为JSON API标准（带有下划线属性）的部分

我应该在哪里进行此转换，以最小化覆盖的JSONAPISerializer Mirage序列化器。

我注意到有一些帮助者，但是我很难将这些知识包装在一起（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

海市rage楼响应的结构：

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]
});

海市rage楼的第一资源模型：

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

Answer 1

让我们尝试着重于一个单一的关系，因为您发布的问题有很多事情要做。我们将看看second-resource。

Mirage似乎在JSON：API有效负载中的second_resource_ids主数据的attributes键下发送了first_resource。这告诉我Mirage认为second_resource_ids是first_resource的属性，实际上它是一种关系。

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

如果您查看Associations section of the Defining Routes guide，则会看到以下消息：

Mirage的数据库将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]
});

但是从Mirage的角度来看，您需要使用camelCase ID或只是传递关系来正确设置它们。像这样：

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之类的内容的格式决定是在< em> serializer 层。处理Mirage的ORM和数据库时，无论序列化程序发出的格式如何，您都希望坚持使用camelCase。

有关更多信息，请查看文档中的以下部分：

Ember Cli Mirage：具有JSONAPISerializer的活动模型适配器

1 个答案: