feat: proxy content type in controller factory #17772
Conversation
|
Do you think it's better to use a proxy here, or a getter? I feel the getter might have a different behaviour and this is a change that can impact custom generated controllers. |
Marc-Roig
added
source: core:strapi
| @@ -6,10 +6,20 @@ const { createController } = require('./core-api/controller'); | |||
| const { createService } = require('./core-api/service'); | |||
| const { createRoutes } = require('./core-api/routes'); | |||
|
|
|||
| // Content type is proxied to allow for dynamic content type updates | |||
| const getContentTypeProxy = (strapi, uid) => { | |||
| return new Proxy(strapi.contentType(uid), { | |||
There was a problem hiding this comment.
I'm not really familiar with the proxy, could you explain a bit what's going on? (also why do we need the get(target, prop))
There was a problem hiding this comment.
a Proxy can wrap any javascript object, and intercept and redefine operations for that object.
With it you can extend how a get access behaves, and leave all the other operations as they were originally (set for example).
Whereas if we only define an object getter:
{
get contentType() {
return strapi.contentType(uid)
}
}we are only exposing the getter of this property, and nothing else.
the get(target, prop) is the interface the tthe proxy get exposes:
target: the original object you are proxyingprop: the property being accessed
|
I did some QA, I can not find anything that this changes breaks. Will wait for your review! :) |
What does it do?
Some dynamically generated attributes (review workflows) were ignored in the core controller sanitizer. Thats because the content type metadata was loaded on startup rather than each time a request is made.
This PR solves the issue by proxying the content type attribute so every time someone get's its values it gets the latest content type data.