简体   繁体   中英

What does the “pull-based functional reactive program” mean in Glimmer VM?

As I saw the notion "pull-based functional reactive program"" in this article: https://engineering.linkedin.com/blog/2017/06/glimmer--blazing-fast-rendering-for-ember-js--part-2

As I know, the "pull-based" means we have to use a regular polling way to check and update the UI according to the latest value of the states. But I think there would be a lot of wasteful "polling" and may even cause the inefficiency of the app running if the app has a lot of states and they are actually not frequently changed most of the time.

So, I think there should be something I missed here, how can I understand that?

While a VM architecture is a novel way of modeling rendering, the initial execution of the VM sets up Reference and Revision Tag subsystems, which allow us to model a pull-based functional reactive program (FRP) used for updating the UI. What this means in practice is that there is no notion of observers or subscriptions to keep values updated in the UI, but rather that we allow the backing values in a template to freely mutate. For now, the simplest way to conceptualize this system is something like the following:

I'd highly recommend Chris Garrett's set of blog posts on this . He does a much more comprehensive job of explaining this, but push vs pull reactivity isn't about polling at intervals for a change it is much more akin to imperative vs declarative programming. It places the onus for reacting to changes in state onto the consumer (pull) as opposed to placing the responsiblity of notifying the app about state changes onto the changer (push).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM