I think we are adding more complexity that is a sibling feature to fastify.io/docs/latest/Reference/Server/#schemacontroller (i.e. the goal is already possible by a feature already included).

Well, is kinda possible by providing the SchemaController, as you can store the reference somewhere and just decorate the Request with the function you want, but that requires overwriting the SchemaController by providing one by yourself, then in case the developer is not interested in using a custom validation library but the default one provided by Fastify, is not so easy to achieve.

The only reason I didn't go in that way was because of the encapsulation, as one of the easiest ways to do so is just exposing the SchemaController and allowing the implementation to do whatever it wants with it. But stills, as Fastify allows to not only overwrite the controller within an encapsulated context but also at a route level, the number of combinations and cases increases.
So my idea was just to keep everything as it is and intercept the SchemaController to provide a smaller function that validates/serializes on runtime, respecting whatever customization has been by the implementation and any level

Can you please add a unit test?

@mcollina I’ll follow @Eomm suggestion and create a standalone file just for testing the new methods. I’ll use his suggestion for create many tests as I can think off at different context levels

Sorry for being like a ghost lately. Changed jobs, and laptop so I'm needing some time to setup everything once again. I hope to bring more activity to it by the end of the week 🙂

Just one though waiting for the docs:

We could split the caching component into a separate PR.
Doing so we could discuss a bit in a separate issue.
Adding it would improve the feature for sure, but a basic version without cache would be good IMHO.

My doubt comes from the following example: the weakmap won't match and the schema will be always recompiled because the object is always a new one:

    fastify.get('/', (req, reply) => {
      const validate = req.compileValidationSchema({ type: 'object', ...etc })
    })

The user should use this function like this to benefit from the weak map:

    const aschema = { type: 'object', ...etc }
    fastify.get('/', (req, reply) => {
      const validate = req.compileValidationSchema(aschema)
    })

This would ease the merge of this PR too

I hope to see land it soo 😄

Sure! I think we can go and apply the suggestions from @mcollina and open a separate PR where we can discuss more in big detail an improvement in the shape of the caching, as because of what you already stated, it's easy for the user to implement it in such way that they will never benefit for the cache.

I think as a first iteration just documenting what's the best approach can help to see how everything goes on a first run meanwhile improving that feature specific 🙂

Thankfully I'm free from Tomorrow on so I'll start adding the missed documentation, applying suggestions, and also adding the TS types. Sorry for the delay, has been a rough week.

Please feel free to have a look, I think is good to go in this state. Just the documentation is missed, I'll add it Tomorrow 🙂

CI is failing

Coverage is low, let me take a look 👍

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.