Skip to content

A better way for customizing built-in models and models from components #397

@bajtos

Description

@bajtos

Consider an application with a "User" model that has few extra properties or methods compared to the built-in User model.

At the moment, the recommended solution is to create a user model extending the built-in User model, which is rather silly.

What we would like to have instead

Support redefine:true as an alternative to base: "User". A redefined "User" model is defined in common/models/user.json and scaffolded by yo loopback. This will allow redefinition of common models in the server facet.

In the long term (loopback 3.x), we were discussing a mixin-based approach, where User would be just a thin wrapper mixing in login/logout and other features provided by the current User implementation.


Original issue description

Possible solutions:

  1. Implement namespaces, move all built-in models to loopback namespace. Application models can live in the global namespace, i.e. User extends loopback.User.
  2. Implement means allowing applications to modify the built-in models, so that they can use them directly.

See also loopbackio/loopback-datasource-juggler#119

A probably related problem: the canonical project layout has three facets - "common", "server", "client". In many cases it is needed to provide different implementation of model methods on the server. The current approach is to create a new "server" model extending the shared "common" model and make any changes in this subclass. While this keeps the design clean, it's also rather cumbersome.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions