GithubHelp home page GithubHelp logo

Comments (3)

dphfox avatar dphfox commented on May 7, 2024 2

The yielding restriction only exists because of two reasons:

  • all state objects must update instantly so the state stored in the reactive graph is always internally consistent
  • any time dependencies are being captured, a yield may cause the automatic dependency manager to break

Observer does not store state, and does not interface with the automatic dependency manager. Therefore there's no good reason to block yielding here in my mind. It's meant to be an escape hatch for when you need to do something in response to a reactive graph change which you would otherwise not be able to express.

I don't think it should be Fusion's job to babysit code of that nature. Do you have a compelling concrete scenario where disallowing yielding for the reason you gave would be of substantial value to the developer?

from fusion.

dphfox avatar dphfox commented on May 7, 2024 1

I'm deferring this to v0.3, since we're redoing how dependency management works there. This will change one of the assumptions upon which this issue depends upon; since there will no longer be an automatic dependency manager, and the flow of dependencies will be made explicit in user code, yielding will no longer break this.

This means that, as long as we can address having the reactive graph always be in a deterministic, internally consistent state, there may actually be merit to allowing for some of these objects to yield. Perhaps this may relate to #4?

from fusion.

nottirb avatar nottirb commented on May 7, 2024

Was toying around with some stuff and came across some issues that might come up, should an Observer's update function be allowed to "yield". I say "yield" here because we currently call coroutine.wrap(callback)(), but I pose the thought that we should change this to dontYield(callback), along with #99.

My basis for this is that if you yield in an observer callback, there's no guarantee that state will be the same before and after the code that yields occurs. I think by default this should be changed to dontYield(callback), and if someone has a specific scenario where they need to yield (for whatever reason), they can just put coroutine.wrap() or something similar in their callback code.

WDYT?

from fusion.

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.