Loopback: New type: ENUM

[bajtos]

Implement a new property type - enum (enumeration).

Example model definition:

{
  "name": "Person",
  "properties": {
    "sex": {
      "type": "enum",
      "values": ["male", "female", "other"]
    }
  }
}

Example remoting argument definition:

{
  accepts: { 
    arg: 'sex', type: 'enum', values: ['male', 'female', 'other'],
    http: { source: 'query' }
  }
}

Implementation details:

• support both "string" and "number" as a backing datatype
• [ ] strong-remoting should validate and coerce enumeration types
• [ ] loopback-datasource-juggler should validate property values of enum type
• connectors should map enum type to appropriate database counterpart
  
  
  
  • [ ] SQL connectors - see https://github.com/strongloop-internal/scrum-loopback/issues/603
  
  
  • [ ] MongoDB - see https://github.com/strongloop-internal/scrum-loopback/issues/604
  
  
• [ ] loopback-swagger should emit correct json-schema descriptor for enum properties
• [ ] autodiscovery

[raymondfeng]

Instead of introducing a new type, I would prefer to add a enum constraint to model properties, such as:

color: {
  type: 'string',
  enum: ['red', 'green', 'blue', ...]
}

It's similar as https://github.com/hapijs/joi#anyvalidvalue---aliases-only-equal

[bajtos]

Instead of introducing a new type, I would prefer to add a enum constraint to model properties

Sounds good :+1:

[violet-day]

+1

[bajtos]

FWIW, we already have ENUM validation implemented via MyModel.validatesInclusionOf('gender', {in: ['male', 'female', 'other']});

I guess we only need to map enum property flag to validatesInclusionOf and implement support for enum in strong-remoting.

[ainesophaur]

+1

Would these additions then translate to loopback explorer? It'd be nice to show the allowed values.

[billinghamj]

+1

[gausie]

:+1:

[Bramanga]

:+1:

[ezraroi]

+1

[MyNameIsURL]

+1

[terehov]

+1

[parvbhullar]

+1

[maykefreitas]

+1

[geoand]

+1

[riteshjagga]

+1

[ataraxus]

+1

[g3k0]

+1

[ghost]

+1

[MarkAndrewJohnson]

The benefit of making this a type instead of a loopback option is that if you need to provision for a secondary access method which isn't via loopback then the enum won't validate the input. Obviously not every use case by far but worth keeping in mind.

[AndreasPizsa]

+1

Enums are a common pattern; adding enum support - whether as a type or a constraint - would greatly simplify repeated validity checks on parameters.

[adrien-candiotti]

+1

[yadavji83]

+1

[lucasftp]

+1

[FluxAugur]

+1

[raghav135]

Same example can be thought of as a enum which is defined in type registry as a "custom type".

And in model, have property as type : "sex"

So that adding a new entry in enums can be done in central type registry?

[martinjuhasz]

:+1:

[timneedham]

:+1:

[evinw]

+1

[daxsorbito]

+1

[FoysalOsmany]

+1

[seanmangar]

+1

[gzurbach]

+1

[shelbys]

@bajtos - FYI, we already have enum validation in our Fork, see: https://github.com/strongloop/strong-remoting/compare/master...shelbys:master We're getting ready to upstream again anyway, when I coincidentally saw this

[ShaharHD]

+1
@shelbys do you plan to have pull request with that specific change (enum)?

[sebastianhaas]

+1

[hulutter]

+1

[aws-na-ss-usplu]

What the status?
+1

[Undrium]

+1

Sweet type or constraint, would organize alot for our project

[PowerP]

+1

[lsroman]

+1

[aws-na-ss-usplu]

Novice: Our very small two cents _;-)_

We currently develop solutions in two worlds… LoopBack/Node.js & WebApi/Asp.net

We would love to have a solution that complements each others interpretation of the concepts around

• Generic Extensions for Enum
• Implement of Enum
• Solution path to transition from Swagger Extension to first class member of Swagger 2.x schema

We currently use swagger to generate both client/server code for LoopBack & .NET, and client code in Java and PHP. When it comes to Enum and Additional Properties we have to deal with exceptions because like HTML specs each community is interpreting the specifications a little differently rather than each community discussing the discrepancy to improve the understanding and interpreting of the Swagger Specs.

Here is how AutoRest community is currently dealing with Enums with AutoRest

• Azure's AutoRest Generic Extensions
• AutoRest x-ms-enum
• Enums with x-ms-enum definition
• AutoRest Enum Github Issue#393

We still need to investigate where the StrongLoops/ IBM thoughts on implementing Enum, and we plan to review shortly.

We just propose that all participants in providing a Swagger Code Generators to deal with Enum to converge on a solution rather than have a lot of silo implementations of swagger generic extensions for Enum.

We have investigated the following code generators to date. Non have a consist implementation to deal with Additional Properties or Enum

• Azure AutoRest
• NSwag
• Swagger-API Online Editor
• Swagger-API CodeGen
• Loopback Swagger Generator

Appreciate feedback, concerns and issues with our thoughts…

[juanpujol]

👍

[fargozhu]

+1

[edoswaldgo]

👍

[petrlyapin]

+1

[rflipo-dev]

👍

[mamartins]

+1

[jamesobd]

+3

[younes200]

Hi,
Is this feature still planned ? which release, version it may be available ?
Thank you.
Cheers
/Y

[siyb]

+1

[BoLaMN]

I do this in my json files with a mixin I wrote for validations link

validations:
  colour:
    inclusion: 
      in: [ 'red', 'blue' ]

[neoPix]

+1

[raymatos]

Is this resolved? Or is there a best practice for enums?

[chadwithuhc]

👍

[joseluisjb1990]

+1

[phil-hawkins]

+1

[hoangtrongphuc]

I have a solution and I'm using it in my project:
In model Game :

color: {
  type: 'string'
}

In game.js file:

module.exports = function(Game) {
  Game.validatesInclusionOf('color', {in: ["hello", "bye"]});
};

[hckhanh]

[phone]

[scippio]

+1

[kjdelisle]

Feature development on [email protected] is winding down as a result of our push towards loopback-next. Given the nature of the new framework and its use of TypeScript, support for things like enums will be much easier to implement going forward rather than on this current version.

[terehov]

Does it mean that loopback-next is around the corner and there is a clear migration path?

[kjdelisle]

Loopback-next is going into beta soon and will consist of the most core components of the framework. The intention of the new platform is to focus more of our energy on providing a solid foundation, rather than attempting to build every connector and component for everyone.

Migration
There is a repository implementation called the legacy-juggler-bridge that will allow continued use of your JSON model definitions and the existing loopback-datasource-juggler/connectors.

However, there won't necessarily be a direct upgrade path for your application that transforms your existing logic into a [email protected] compatible application. I'd strongly encourage reading the wiki (https://github.com/strongloop/loopback-next/wiki); it's still a work-in-progress but combining it with the loopback-next-example repo should give you insight into loopback-next's many potential workflows and designs.

[kjdelisle]

@terehov Sorry, forgot to add your name to the comment. :P

[SrChip15]

@kjdelisle Where should I look for enum related model data validations in Loopback 4?

[bajtos]

Let's move the discussion to https://github.com/strongloop/loopback-next/issues/3033.

[bajtos]

For anybody who lands in this issue: if ENUMs are important to you, then please up-vote strongloop/loopback-next#3033 by adding a 👍 reaction at the top. Please DO NOT post +1 comments, those are not helpful.