feat(repository): include navigation properties in JSON

[bajtos]

Modify the code converting Model instances to JSON data to include navigational properties for the defined model relations.

See #3171 and #2633

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[nabdelgadir]

👏

[nabdelgadir]

From #3171:

it('includes TodoList in query result', async () => {
    const list = await givenTodoListInstance(todoListRepo);
    const todo = await givenTodoInstance(todoRepo, {todoListId: list.id});
    const filter = JSON.stringify({include: [{relation: 'todoList'}]});
    const response = await client.get('/todos').query({filter: filter});
    expect(response.body).to.have.length(1);
    expect(response.body[0]).to.deepEqual({
      ...toJSON(todo),
      todoList: toJSON(list),
});

This test along with the symmetrical includes Todo test were both failing because:

• When the code reaches https://github.com/strongloop/loopback-next/blob/master/packages/rest/src/writer.ts#L54 (a call to JSON.stringify)
• It comes to this toJSON function
• In this function, since the properties in *Relations aren't decorated by @property and in the model class, then they aren't part of the model definition's properties so they get stripped which is why the test fails.

From @bajtos:

As for describing navigational properties in model definitions: originally, @hasMany was calling @property decorator under the hood. This had its own problems though, for example the navigational properties were then described in the request body of "create" and "update" operations, which is not desirable. That's why we moved away from the design where navigational properties are part of the model schema.

I think we need to find a way allowing Model's toJSON (and toObject) methods to understand that even in strict mode where no extra properties are allowed, the navigational properties should be still included in the result.

[raymondfeng]

nitpick: IIRC, {...} as HasManyDefinition is a recommended style over <HasManyDefinition>{...}.

[bajtos]

Makes sense. From what I remember, when using {...} as HasManyDefinition, TypeScript is not able to offer correct suggestions (auto-completion) for members of the object being created :(