idea: JSON Schema import about objectmodel HOT 4 CLOSED

Yes I've been thinking for a long time about interoperation between ObjectModel and other type systems like Flowtype AST or JSON Schema.

My concern is that these systems have been thought for static type checking, so you lose all the benefits of dynamic type checking features: assertions, custom types, types depending on state or environment...

My goal with ObjectModel is to praise dynamic type-checking and demonstrate its benefits. If you only use static type-checking features, ObjectModel is not the best choice for you. Better use Flowtype and a runtime converter such as babel-plugin-tcomb.

It's always possible to use both of them, for example import a JSON Schema and add assertions afterwards, but will the users do it ? And will it be manageable to have several sources of typing ?

Dynamic and static type checking are different approaches to the same problem and I am not sure this shift of mindset can be done correctly if relying on older formats/conventions. What do you think ?

from objectmodel.

Thanks @sylvainpolletvillard for the quick reply.

I can't see why the dynamic type checking should not work if we define the model in JSON Schema at first.

Exampe 1: Schema as JS object literal

const Schema = {
    product: { name: String, quantity: Number },
    orderDate: Date
};

Exampe 2: Schema as JSON Schema
Here it would make sense to import the schema from filesystem instetead of typing it here...

const JSONSchema = '{
  "title": "Order Schema",
  "type": "object",
  "properties": {
    "product" : { "type": "string", "quantity": "integer", "minimum": 0 },
    "orderDate": "date"
  },
  "required": ["product","orderDate"]
}';

// convert() could convert JSON Schema like needed...
const Schema = convert(JSONSchema);

Model initialisation would be the same then

const Order = new Model(Schema);

Then Order could be the used as ObjectModel like normal.
The idea behind using JSON Schema in my case is to have a unified text based schema language between different microservices / apps.

from objectmodel.

Oh, it would totally work, this is not my point. tcomb is doing it and I could also write a converter for JSON schema quite easily. I'm just concerned that by doing this, people miss the point of the library.

You see, JSON Schema is a large specification trying to cover most of users needs, but not all of them. Imagine that the minimum quantity of a Product depends on the product category. This is not something you would be able to express with JSON Schema, so you would do it with additional logic in your code, separately from typechecking ; while with ObjectModel, you don't have these constraints. It's not only doable, but I also encourage you to do it and express more of your logic in the models. Hence the slogan of this library, "More than just type-checking".

I understand your needs for a unified type system between client and back-end services, but in your case you will have to use the lowest common denominator of these type systems, so you can't benefit from the features that make this library interesting, in my opinion. So I wonder if this is the right choice for you, to be honest. I do not want to sell you my lib at all costs if it does not respond to your use case.

Anyway, this is something I have been thinking about for over a year and I'm still not sure what direction I want to give to ObjectModel. Your feedback would be very valuable. Since you already know tcomb, could you tell me what do you like in ObjectModel compared to other existing solutions ? Thanks

from objectmodel.

Thank you @sylvainpolletvillard for your explanation.
I like the clear API and good documentation. Also i like the main feature of dynamic type checking.

But you're right. It might not be the best fit for my goals.

from objectmodel.