Reactive.coffee: reactive programming and declarative UIs in CoffeeScript • Hacker News Board

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#21

Post by madzanderzen » Wed, Aug 07, 2013, 7:45 PM UTC

xyzzyrz wrote: post #18

madzanderzen wrote: post #17

Earlier quoted context omitted.

Thanks for the explanation in the link. The problem that is described in the link is clearly solvable, however what I'm referring to is more fundamental. I'm not talking about nested binds, but just a simple bind such as "z = bind -> x.get() + y.get()". This will add listeners to x and y. When will those listeners be removed again (without adding new ones during the recalculation of z's new value in case of a change…

Yeah, this is what I'm talking about - a fuller explanation would require more text. :) The question is what you're doing with z. As long as you're also adding and removing your hypothetical panels in turn with bind, you're good: div {class: 'container'}, bind -> [ if show.get() div {class: 'z'}, bind -> x.get() + y.get() else div {class: 'nothing'} ] The question is what happens at the top level or when you want to…

Ahh, you're putting the entire UI in binds. That's a really clever way to handle the lifecycle of the listeners!

bind is "stupid" in the way that it completely recalculates a cells value on any change of a cell it's previous calculation depended on. It doesn't "understand" the calculation in a way to only recalculate the part that was strictly needed to update its value to a change.

I mention this because if the entire UI is in a bind, then on every change the entire UI would be recreated. I worry that this could get prohibitively slow on a sufficiently complex UI? (It can also lead to problems with widgets losing focus, but that can be solved in a similar way as in Immediate Mode GUI's).

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#22

Post by xyzzyrz » Wed, Aug 07, 2013, 8:14 PM UTC

tqs wrote: post #20

This is a really nice cleanup/update on Knockout. The source code at ~400 lines is very understandable. I've looked at a lot of reactive frameworks, this is great work! I'm glad you're thinking about how to manage garbage collection. It's tricky with these push-based frameworks. Have you given consideration to asynchronous vs synchronous reactivity? The advantage of asynchronous is you don't propagate the changes as…

Yes! There's already a lag-delay primitive, but it's a one-off hack we needed to get things working - more general asynchronous propagation is definitely a requirement.

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#23

Post by alipang » Wed, Aug 07, 2013, 8:20 PM UTC

xyzzyrz wrote: post #19

invalidOrTaken wrote: post #16

Do you feel that you've lost anything in terms of composeability as compared to a more stream/combinator-oriented approach, like, say, Flapjax? If so, have you found that painful in the real world, or do you think it's more of an academic concern with little meaningful impact?

Good question - the reason why we built the library this way was exactly because we find declaring expressions to be more natural than wiring together streams by combinators—which, BTW, Flapjax does support. Far from academic-without-impact, Leo's work was actually directly influential on me—esp. since he worked in PL and I didn't, so much of my initial exposure to reactive programming came from a few projects includ…

I'm a big fan of bacon.js. Is there any way you can abstract over values over time, or asynchronously? This was always my big problem with knockout.

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#24

Post by xyzzyrz » Wed, Aug 07, 2013, 8:29 PM UTC

madzanderzen wrote: post #21

xyzzyrz wrote: post #18

Earlier quoted context omitted.

Yeah, this is what I'm talking about - a fuller explanation would require more text. :) The question is what you're doing with z. As long as you're also adding and removing your hypothetical panels in turn with bind, you're good: div {class: 'container'}, bind -> [ if show.get() div {class: 'z'}, bind -> x.get() + y.get() else div {class: 'nothing'} ] The question is what happens at the top level or when you want to…

Ahh, you're putting the entire UI in binds. That's a really clever way to handle the lifecycle of the listeners! bind is "stupid" in the way that it completely recalculates a cells value on any change of a cell it's previous calculation depended on. It doesn't "understand" the calculation in a way to only recalculate the part that was strictly needed to update its value to a change. I mention this because if the enti…

A bind only re-evaluates if changes happen within its own immediate scope, and not if the changes are within any descendant binds' scopes. Whenever you want to carve off finer-granularity updates, scope things to a separate bind. This has scaled to, for instance, a complex WYSIWYG web page editor, where the whole page/document being edited is structured using cells and rendered with recursive binds - the app needs to be very responsive to each change a user makes, whether it's typing in text or dragging a style slider, even if the focus is on the top-level DOM element. That's not to say we've seen all the use cases - we definitely want to see where things fall down as well.

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#25

Post by madzanderzen » Wed, Aug 07, 2013, 9:10 PM UTC

xyzzyrz wrote: post #24

madzanderzen wrote: post #21

Earlier quoted context omitted.

Ahh, you're putting the entire UI in binds. That's a really clever way to handle the lifecycle of the listeners! bind is "stupid" in the way that it completely recalculates a cells value on any change of a cell it's previous calculation depended on. It doesn't "understand" the calculation in a way to only recalculate the part that was strictly needed to update its value to a change. I mention this because if the enti…

A bind only re-evaluates if changes happen within its own immediate scope, and not if the changes are within any descendant binds' scopes. Whenever you want to carve off finer-granularity updates, scope things to a separate bind. This has scaled to, for instance, a complex WYSIWYG web page editor, where the whole page/document being edited is structured using cells and rendered with recursive binds - the app needs to…

Nice! Thanks for taking the time to explain this :-)

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#26

Post by madzanderzen » Wed, Aug 07, 2013, 9:26 PM UTC

xyzzyrz wrote: post #24

madzanderzen wrote: post #21

Earlier quoted context omitted.

Ahh, you're putting the entire UI in binds. That's a really clever way to handle the lifecycle of the listeners! bind is "stupid" in the way that it completely recalculates a cells value on any change of a cell it's previous calculation depended on. It doesn't "understand" the calculation in a way to only recalculate the part that was strictly needed to update its value to a change. I mention this because if the enti…

A bind only re-evaluates if changes happen within its own immediate scope, and not if the changes are within any descendant binds' scopes. Whenever you want to carve off finer-granularity updates, scope things to a separate bind. This has scaled to, for instance, a complex WYSIWYG web page editor, where the whole page/document being edited is structured using cells and rendered with recursive binds - the app needs to…

Just one last question...

Say I have something like a button with an action, and the action has a cell whose value is used when the action is executed by clicking the button.

If I create the button in a bind, and the cell in the action is also made with a bind, but during the calculation to create the button the cell for the action is never actually read, then no listeners will be attached to the cell for the action, and the cell will therefore not update itself to underlying changes.

Now sometime later I click the button, but the cell for the action has an expired value, what happens?

I guess my question is, what happens when the reading of a cell value only happens outside the evaluation of binds?

One solution could be to always add a listener to new reactive cells created during a bind, another solution is simply to evaluate a cell everytime it's value is requested when it has no listeners added.

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#27

Post by xyzzyrz » Thu, Aug 08, 2013, 2:19 AM UTC

peterhunt wrote: post #9

rtfeldman wrote: post #6

This looks like just the sort of thing I've been looking for. Reactivity is very convenient, but it's so often tangled up in a massive library that's trying to do much more at once. I've learned the hard way to embrace the "best in breed small libraries" philosophy over the "monolithic do-everything framework" approach, and I'm particularly excited to see a small, simple reactive library that goes as far as to use ef…

You may be interested in what we've built with React ( http://facebook.github.io/react/ ). We're focused exclusively on rendering and wiring up event handlers and offer a super straightforward, highly performant reactive programming model. There is some particularly interesting technical aspects around how we keep state consistent between React and the browser as well as how we've architected the core (it's a bit lik…

Hi Peter - React is great! To those of you who haven't already, go check it out. It shares a lot of similarities with reactive.coffee (besides our highly original names), including the "code-first" approach to building up views.

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#28

Post by xyzzyrz » Thu, Aug 08, 2013, 2:33 AM UTC

madzanderzen wrote: post #26

xyzzyrz wrote: post #24

Earlier quoted context omitted.

A bind only re-evaluates if changes happen within its own immediate scope, and not if the changes are within any descendant binds' scopes. Whenever you want to carve off finer-granularity updates, scope things to a separate bind. This has scaled to, for instance, a complex WYSIWYG web page editor, where the whole page/document being edited is structured using cells and rendered with recursive binds - the app needs to…

Just one last question... Say I have something like a button with an action, and the action has a cell whose value is used when the action is executed by clicking the button. If I create the button in a bind, and the cell in the action is also made with a bind, but during the calculation to create the button the cell for the action is never actually read, then no listeners will be attached to the cell for the action,…

Think of cells (including binds) as just containers: when you call .get() (inside or outside a bind), you just get the currently stored value. Besides the container abstraction for its own sake, values also enable the scoping effect described earlier - if you have x.get() + y.get(), and x updates, you don't need to re-evaluate y (which in turn may be a bind - its body is scoped off so that you're not re-evaluating an entire sub-graph of the application). They're also necessary groundwork for smarter propagation strategies, e.g. stopping propagation if the value hasn't changed.

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#29

Post by xyzzyrz » Thu, Aug 08, 2013, 2:34 AM UTC

madzanderzen wrote: post #25

xyzzyrz wrote: post #24

Earlier quoted context omitted.

A bind only re-evaluates if changes happen within its own immediate scope, and not if the changes are within any descendant binds' scopes. Whenever you want to carve off finer-granularity updates, scope things to a separate bind. This has scaled to, for instance, a complex WYSIWYG web page editor, where the whole page/document being edited is structured using cells and rendered with recursive binds - the app needs to…

Nice! Thanks for taking the time to explain this :-)

These are great questions! The topics deserve attention from the docs, esp. regarding suggested ways of doing things (e.g. the `shown` example from earlier vs. imperatively adding/removing elements).

Re: Reactive.coffee: reactive programming and declarative UIs in CoffeeScript

#30

Post by peterhunt » Thu, Aug 08, 2013, 7:24 AM UTC

xyzzyrz wrote: post #27

peterhunt wrote: post #9

Earlier quoted context omitted.

You may be interested in what we've built with React ( http://facebook.github.io/react/ ). We're focused exclusively on rendering and wiring up event handlers and offer a super straightforward, highly performant reactive programming model. There is some particularly interesting technical aspects around how we keep state consistent between React and the browser as well as how we've architected the core (it's a bit lik…

Hi Peter - React is great! To those of you who haven't already, go check it out. It shares a lot of similarities with reactive.coffee (besides our highly original names), including the "code-first" approach to building up views.

Yep glad that we're validating each other :) Also ractive too!