GithubHelp home page GithubHelp logo

Comments (5)

sdegueldre avatar sdegueldre commented on July 16, 2024 1

Hm. Because rendering is async, it's possible that the condition on the component could have been true when Owl evaluated the condition on the component, and that the condition has become false before Owl gets to render the slot. In the typical case, when there are no willStart hooks registered, there is one microtask of delay between the creation of a component and its rendering.

Here is a simple example reproducing the issue on the playground

Now obviously nobody would do this on purpose but you can see how it might happen by accident under specific circumstances.

Long term, I'd like for Owl to give stronger guarantees with regards to rendering synchronicity but as it stands, Owl only guarantees "semi-synchronous" rendering for components that don't use async hooks (willStart/willUpdateProps). Semi-synchronous in this context meaning that the rendering will be finished before the next macrotask in the queue is processed. Unfortunately Owl also doesn't give any guarantees that the render will start in the next macrotask so it's not particularly difficult to schedule a render and then having promise chains invalidate the state that is currently being rendered.

from owl.

seb-odoo avatar seb-odoo commented on July 16, 2024

Thank you for the investigation, the example is even more simple than I imagined!

Are you implying it is not going to be fixed for now?
And if so, shouldn't we defensively re-add conditions on every component? Only inside slots?

from owl.

sdegueldre avatar sdegueldre commented on July 16, 2024

@ged-odoo what do you think? I think I still have that one branch somewhere that makes rendering fully synchronous when possible and it may solve this problem.

from owl.

ged-odoo avatar ged-odoo commented on July 16, 2024

this is really interesting, and complicated. the issue is much larger than slots: basically, since there is a period of time between component is instantiated and when it is rendered, there also may have changes that cause the component to be invalid.

making owl semi-synchronous would reduce the surface area of that problem, but it is not a complete solution. (note that i am not against the change, just afraid of it)

from owl.

ged-odoo avatar ged-odoo commented on July 16, 2024

not sure what to do, but we should talk about it :)

from owl.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.