Joi: Correct way to write an "identity" extension?

[LudwikJaniuk]

(by "identity" I mean "one that changes nothing", similar to the identity function)

Context

• _node version_:6
• _joi version_:9
• _environment_ (node, browser):node
• _used with_ (hapi, standalone, ...):standalone
• _any other relevant information_:I'm extending joi
  

  What are you trying to achieve or the steps to reproduce ?

I'm trying to do a minimal "identity" extension to joi that would replace an existing data type, but not change it in any way, so I'm using it as the base.

var joi = require("joi");
joi = joi.extend({
    name: "object",
    base: joi.object(),
});

Which result you had ?

joi.object() seems to be behaving slightly differently, it has something to do with .options() and .keys() and allowUnknown changing their behavior. I will construct a minimal example demonstrating this if it's not obvious what I'm doing wrong.

What did you expect ?

I expected the new joi.object() to work exactly as before, and change nothing in how the new joi object behaves. Was that assumption correct? Is this how you would write an "identity" extension?

[Marsup]

Not sure I understand, identity is joi.any() for me.

[LudwikJaniuk]

No, what I mean is that I want to write an extension that would be a "copy"
of joi.object, that would replace it, and work exactly like it. And I think
I'm doing something wrong.

On Thu, Oct 6, 2016, 12:33 Nicolas Morel [email protected] wrote:

Not sure I understand, identity is joi.any() for me.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hapijs/joi/issues/1000#issuecomment-251925327, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGAbGe3wZSsbwoGhPARcl6QEP9eV54ctks5qxM6JgaJpZM4KPx6L
.

[Marsup]

I'll wait for your example to see if there's anything wrong with type overriding, I think it's tested.

[LudwikJaniuk]

Ok, will post it soon.

On Fri, Oct 7, 2016, 02:23 Nicolas Morel [email protected] wrote:

I'll wait for your example to see if there's anything wrong with type
overriding, I think it's tested.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hapijs/joi/issues/1000#issuecomment-252124269, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGAbGSNojpaUkMO6vUJ4Ls8I16d92QOJks5qxZEEgaJpZM4KPx6L
.

[LudwikJaniuk]

Here is a minimal example. This validation fails with "a" is not allowed:

var joi= require("joi");
joi = joi.extend({ name: "object", base: joi.object() });

var schema_a = joi.object({ a: joi.number(), }).options({allowUnknown: false});
var schema_b = schema_a.keys({ b: joi.any(), });

var subject = {
  a: 3,
  b: 4,
};

joi.assert(subject, schema_b);

But this one succeeds (line 2 commented out):

var joi= require("joi");
//joi = joi.extend({ name: "object", base: joi.object() });

var schema_a = joi.object({ a: joi.number(), }).options({allowUnknown: false});
var schema_b = schema_a.keys({ b: joi.any(), });

var subject = {
  a: 3,
  b: 4,
};

joi.assert(subject, schema_b);

I assumed the new joi.object would be just like the old one, and that's why I'm surprised by this behaviour ^{and it's breaking my tests}

[LudwikJaniuk]

@Marsup But maybe I'm just doing something wrong, and this is not the correct way to write a "copy" of joi.object()?

[Marsup]

You're using an api that's a shorthand to joi.object().keys() (https://github.com/hapijs/joi/blob/master/lib/index.js#L74) that's not really part of the object type, when extending you're not bringing this with you. Extending the constructor is not yet possible, I might consider this in the future if there's enough demand for it.

[LudwikJaniuk]

Oh, so when specifying base, the methods don't follow along into the new type? That's a shame, but now I have a better understanding of why this was failing. Any suggestions on how to work around this? Could I create a new type that would have new rules + the functions of an existing type? If not, I guess the plan B if there is no better option, would be to create a new type with the extension rules, and use joi.and to test agains joi.object and this one.

[Marsup]

Just use Joi.object().keys() instead of the shorter version in the meantime.

[LudwikJaniuk]

Oh, so it's only special features of the constructor that don't get carried over. Now I understand, and I can easily work around this. Thanks!

I'm satisfied and could close this issue as for me, but you said you'd maybe implement this in the future, so perhaps you want to keep it open?

[Marsup]

Indeed this could be an interesting feature so I'll keep this open. Even mark it as open for contributors.

[talyssonoc]

Do you intent to support it? If so, I can try to send a PR to add the option to pass arguments to custom extensions.

[Marsup]

Arguments are in my plans but it needs careful design because of inheritance, I didn't have time to think about it so far.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.