0

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

开发环境的实际状态是：

我使用Active Model Adapter结构向后端请求资源，后端使用JSON API结构响应我。

在我正在使用的应用程序序列化程序中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 Serializer 应该获取请求（查找之前在具有关联的测试中创建的资源），然后使用 JSON API 格式对其进行响应 ---> JSON API Serializer 可以捕获它并填充 Ember DS。

现在，我有一个缺失的部分来将所有情况下的它序列化为 JSON API 标准（带有下划线的属性）

我应该在哪里进行此转换以最小化覆盖 JSONAPISerializer Mirage Serializer。

我注意到有一些帮助者，但我有一个问题将这些知识包装在一起（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"
      }
    }
  ]
}

更新2

海市蜃楼响应的结构：

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

mirage 中的 first_resource 模型：

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

1 回答 1

2

让我们尝试关注单一关系，因为您发布的问题有很多内容。我们来看看second-resource。

看起来 Mirage 是在 JSON:API 有效负载中的主要数据的密钥second_resource_ids下发回的。这告诉我 Mirage 认为是 的一个属性，而实际上它是一种关系。attributesfirst_resourcesecond_resource_idsfirst_resource

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

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

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 的角度来看，您需要使用camelCaseID，或者只是传递关系，才能正确设置这些。像这样的东西：

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-attributevs.some_attribute或relationship-idvs.之类的东西relationship_id）的格式决定是在序列化层做出的。在处理 Mirage 的 ORM 和数据库时camelCase，无论您的 Serializer 发出何种格式，您都希望坚持使用 .

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

于 2019-03-10T19:05:49.607 回答