Recursive object properties

[matthyk]

Well, it's me again :smile: I currently use this plugin heavily to implement the use case already mentioned in #93. I am currently generating mock plugins to perform isolation tests. It would be very helpful if I could not only get the object type for decorators but also the properties of this object (already mentioned in #92). Something like this:

app.decorate('objectDecorator', {
  str: 'hello',
  recursiveObj: {}
})

would result in

{
  name: 'objectDecorator',
  type: 'object',
  recursive: [
    { name: 'str', type: 'string' },
    { name: 'recursiveObj', type: 'object', recursive: ... }
  ]
}

The user of this plugin could control the depth of the recursive object properties by a plugin option like maxDecoratorDepth or something similar. If this is outside the scope of this plugin this is fine and I can implement it outside this plugin, but it would be nicer and usable for others within this plugin 😄 If you are open for a PR, I am happy to provide a first implementation :)

Thanks for all your work!

[Eomm]

What about the onDecoratorDefinition(type: request|reply|server, name, rawItem:any) function option?

[matthyk]

This method would then be called with the above example as follows?

onDecoratorDefinition('server', 'objectDecorator', {
  str: 'hello',
  recursiveObj: {}
})

What would then be done with the return value of this method?

[matthyk]

You mean like in #96 with the onRouteDefinition? This could work pretty well.

[Eomm]

What would then be done with the return value of this method?

Correct, so the user can decorate the "base" fastify-overview object adding a whatever datastructure such as the schema of the object itself

[Eomm]

My only doubt - set 3 different functions? Maybe it is better

• onRequestDecorator
• onReplyDecorator
• onServerDecorator

[matthyk]

I would prefer the 3 different functions as options. It would have the following advantages:

• It's more Fastify style since we also have 3 different decorate functions
• we can avoid that the devs have to Check the decorator type within the single function
• If one want to use the Same function for all three types, just use one function for all three options

[matthyk]

I have implemented the first version and changed my mind. It is much easier to implement if you only have one option onDecoratorDefinition. In addition, you will probably use the same logic for all 3 types of decorators more often than less and if you want separate logic for the 3 decorators, you can do this with a simple case distinction.