Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New props in a component that propagate to all extensions #1628

Open
manuelregidor opened this issue Jul 15, 2024 · 1 comment
Open

New props in a component that propagate to all extensions #1628

manuelregidor opened this issue Jul 15, 2024 · 1 comment

Comments

@manuelregidor
Copy link

I am trying to add some new props to the Many2XAutocomplete component in a new module. I am doing the following:

Many2XAutocomplete.props = {
    ...Many2XAutocomplete.props,
    nodeOptions: {type: Object, optional: true},
};

I need this new prop to be available in all the components that extend the Many2XAutocomplete component. However, it doesn't seem to propagate. For instance, the module partner_autocomplete also extends the Many2XAutocomplete component with component PartnerMany2XAutocomplete, but I get the props validation error (Invalid props for component 'PartnerMany2XAutocomplete': unknown key 'nodeOptions') when I try to use the values added in the nodeOptions prop in my module.

I could individually add this new prop definition to the PartnerMany2XAutocomplete component, but that would generate a dependency on the module partner_autocomplete that I would like to avoid.

Is there any way to add new props definitions to a component and make them available in all the components that extend it so those props can be used and the validation error does not occurr?

Thank you

@sdegueldre
Copy link
Contributor

This is unrelated to Owl itself, in the future you should ask these kinds of questions on the odoo forums (or maybe on the odoo/documentation repo).

Because of the way that component extensions extend props, there is no great way to do what you're trying to achieve, something that can work is to "prepend" your patch in the assets bundle, this will cause it to be loaded right after all its dependencies are fulfilled and likely before all extensions of the base component. Not super robust but will work in a pinch. Generally, modifying the public API of a component in place is not a great idea though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants