Try the "blaze-refactor" branch!

[David Greenspan]

Hi everyone,

We've just completed a refactor of Blaze which preserves the public API but simplifies the internals, in order to address technical debt from the 0.8 release and make Blaze a comprehensible and lasting library that can serve as a solid foundation for what's to come.

Please test your apps and packages on the "blaze-refactor" branch.  It’s entering QA and will be released in a couple weeks or so.  Now is the time to port your packages and give us any feedback.

Note that most apps and packages will not have to change at all.  Even the latest and experimental APIs are the same, like UI.dynamic and _uihooks.  UI.render is now joined by the new UI.remove.

Let us know if you have any questions or trouble with your code!

Technical Details:  I know a number of you have been digging under the hood of Blaze for a while, and have discovered UI.Component and the Component tree.  This "Component API" didn't provide a full-fledged modular UI system; it's usefulness lay in exposing the view tree in a concrete way.  That's why we've slimmed down UI.Component and refashioned it into Blaze.View.  The View tree replaces the Component tree.  If you've hooked into Blaze at the Component level at all -- which we've kept very quiet about -- you'll almost certainly find a way to do the same thing with Views.  I look forward to talking more about Views and why they are cool in the coming weeks.  We still plan to develop patterns for forms and component classes as part of core, but they are on the post-1.0 roadmap.

Thanks,

David

[Arunoda Susiripala]

Hi David,

That is great. I spent a lot of time to understand current version of blaze by digging into lot of place.

Now place API is pretty simple and really like it.

As a suggestion, we can write instantiateBody with Blaze.render

var instantiateBody = function () {

  if (Template.__body__.__isInstantiated)

    return;

  Template.__body__.__isInstantiated = true;

  Blaze.render(Template.__body__).attach(document.body);

};

I think, that's cleaner than calling __makeView() directly. 

BTW: I need to re-write How Blaze Works article from scratch. I'll wait a bit :)

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[David Greenspan]

That was fast!  Thanks for writing How Blaze Works, btw, and I'm glad you approve of the changes.

I made the change to instantiateBody with a slight elaboration in order to assign Template.__body__.__view (in case someone needs it).

[Arunoda Susiripala]

Ah okay. Got it.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[David Greenspan]

In case my wording was ambiguous, I essentially took your suggestion: https://github.com/meteor/meteor/commit/2c3899f0e8dac80cc92b67deda145e52f13aa03e

[Arunoda Susiripala]

Awesome. That's great.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[Avital Oliver]

BTW Arunoda, in your post I think you misexplained DOMRange. HTMLJS is the DSL for defining a DOM-like data structure, not DOMRange. DOMRange tracks a dynamically changing contiguous block of DOM nodes.

PS. I genuinely *really* like receiving feedback of any kind. Leave it anonymously at http://www.admonymous.com/avital

[Arunoda Susiripala]

Got it Avital. Thanks. I will update the post.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[Abigail Watson]

Hi David,
Congrats on the refactoring.  Always nice to get a big one out the door.

Just out of curiosity, is Blaze.View intended to become a public API?  If so, is that signaling a plan to either polyfill or bypass the CSS system, like Famo.us is doing?  Is the plan to fully integrate Famo.us?  Or is Meteor officially adopting Ruby/Angular and other server-side MVC conventions?

I ask, because using the View namespace causes a bunch of headaches for those of us doing any type of responsive or mobile design, and who are relying on CSS Media Queries to generate device-specific Views.  Almost all modern browsers put a CSS subsystem at the end of the rendering pipeline, and for many developers, that's an important technology in the design process.  I know there are a lot of other libraries out there that use 'View' to refer to HTML or Javascript objects, and most of those libraries ignore the role that the CSS subsystem has in the rendering pipeline, and result in major headaches for mobile webapp developers as a result.  

One of Meteor's strengths has been that it's been fairly neutral about the MVC model that app developers use, and not dictated one approach or another.  However, a Blaze.View API seems to be a step towards assuming a server-side MVC model at the expense of client-side developers.  And unless the intent is to bypass the CSS subsystem, like how Famo.us is doing, I think that approach could wind up being problematic for mobile developers.  

Thanks!
Abigail

[David Greenspan]

Hi Abigail,

I wouldn't read too much into the name View.  If you want something to compare it to, see Ember.View, which, in a similar vein, is an under-the-hood building block that's created by templates but that you can also use directly if you need to:

* http://emberjs.com/api/classes/Ember.View.html

* http://emberjs.com/guides/understanding-ember/the-view-layer/

> This guide goes into extreme detail about the Ember.js view layer. It is intended for an experienced Ember developer, and includes details that are unnecessary for getting started with Ember.

>

> Ember.js has a sophisticated system for creating, managing and rendering a hierarchy of views that connect to the browser's DOM. Views are responsible for responding to user events, like clicks, drags, and scrolls, as well as updating the contents of the DOM when the data underlying the view changes.

>

> View hierarchies are usually created by evaluating a Handlebars template. As the template is evaluated, child views are added. As the templates for those child views are evaluated, they may have child views added, and so on, until an entire hierarchy is created.

>

> Even if you do not explicitly create child views from your Handlebars templates, Ember.js internally uses the view system to update bound values. For example, every Handlebars expression {{value}} creates a view behind-the-scenes that knows how to update the bound value if it changes.

The relationship between the Meteor client and server, and between templates and CSS, will remain the same for the foreseeable future.

-- David

--

[Andrew Mao]

Alright, time to refactor all of the crazy hacks I added to certain packages that were mimicking the Spark rendering behavior in Blaze, i.e: https://github.com/mizzao/meteor-sharejs/blob/master/sharejs-client.coffee#L4.

Do you know (approx.) what version of Meteor this will go into? I'd just like to keep track for the purpose of updating my packages that were using the undocumented Components.

[David Greenspan]

Hi Andrew,

Approximately 0.8.3.  Can you remind me what you need to do?  I bet there's a cleaner way now.

-- David

On Thu, Jul 10, 2014 at 8:59 AM, Andrew Mao <miz...@gmail.com> wrote:

Alright, time to refactor all of the crazy hacks I added to certain packages that were mimicking the Spark rendering behavior in Blaze, i.e: https://github.com/mizzao/meteor-sharejs/blob/master/sharejs-client.coffee#L4.

Do you know (approx.) what version of Meteor this will go into? I'd just like to keep track for the purpose of updating my packages that were using the undocumented Components.

--

[Andrew Mao]

I need to call a function whenever the input data context changed, then call another function when the data is about to change to something else.

I simulated this by creating a one-shot component for every update to the data context and attaching this to the rendered and destroyed callbacks.

[Maxime Quandalle]

Hi guys,

If you want to test the meteor "blaze-refactor" branch with your jade templates, you can now use the "blaze-refactor" branch of the jade package :-)
According to the unit tests, it should work for everything except for helper inside "textarea" tags.

Let me know if you run into any problem :-)

Maxime

[David Greenspan]

Just merged blaze-refactor to devel.

Andrew, you should be able to do something similar with Views.  I tried to understand your code, but I don't see how you avoid losing the old DOM elements and getting new ones when the data context changes; or maybe that's the point.

There are some new "private" calls that may or may not help.  You can get the current data context, reactively, via UI._parentData(0) or Blaze.getCurrentData(), from a helper callback.  You can fire up an autorun from a callback using this.__view__.autorun.

[Chris Mather]

Hi David, is there a reason you can't return a view from an inclusion helper? To return a new view from a helper it looks like you have to create a template using __create__ and return a view from that. Is that what you had in mind?

[Chris Mather]

Hey guys, great job on the refactor. The new API is simpler to reason about. A little snag:

Summary: Best way to isolate inclusion arguments without the help of emboxValue?

Longer Version:

I've been upgrading iron-dynamic-template (on which iron-layout and iron-router depend) and it's gone mostly smoothly with just a few snags. One of them is figuring out the best way to isolate inclusion arguments whose values are functions now that emboxValue is gone.

Let's say you have:

{{> DynamicTemplate template=getTemplate data=getData}}

The goal is to not re-render the entire template just because the getData function reruns.

The first problem is it looks like calling view.lookup('template') will now evaluate immediately and grab the value, also creating a dependency on the Spacebars.include data function. Then when I call view.lookup('data') it also evaluates immediately and creates another dependency. But now, anytime the template OR the data changes, both of those functions rerun, and the template will be taken off the page no matter what.

I'm investigating solutions but thought I'd bring it to your attention while I'm working through it.

Chris

PS - The primary reason for DynamicTemplate vs. {{> UI.dynamic}} is we need to be able to create dynamic templates, set data and templates programmatically as well as in template markup. So it was just easier to build it from scratch.

[Chris Mather]

PPS - It looks like {{> UI.dynamic ...}} has this same issue where the entire template is taken off the page for data context changes. Previously, only the range(s) that used the data would be taken off the dom vs. the entire template.

[Vincent Jaubert]

I'm trying the blaze-refactor branch with my app, it's complaining about 

Exception from Deps recompute function: Error: Can't render the same View twice

at Object.Blaze._expandView (http://localhost:3000/packages/blaze.js?58873cae0cd397939e96493c52ed6101c0a04744:1873:11)

at Blaze.HTMLJSExpander.def.visitObject (http://localhost:3000/packages/blaze.js?58873cae0cd397939e96493c52ed6101c0a04744:1905:20) at HTML.Visitor.def.visit (http://localhost:3000/packages/htmljs.js?fcf2660be84fbc0c33b97ee8932dbd46612f3566:116:31) at HTML.TransformingVisitor.def.visitArray (http://localhost:3000/packages/htmljs.js?fcf2660be84fbc0c33b97ee8932dbd46612f3566:155:32) at HTML.Visitor.def.visit (http://localhost:3000/packages/htmljs.js?fcf2660be84fbc0c33b97ee8932dbd46612f3566:114:32) at HTML.TransformingVisitor.def.visitAttribute (http://localhost:3000/packages/htmljs.js?fcf2660be84fbc0c33b97ee8932dbd46612f3566:243:23) at Blaze.HTMLJSExpander.def.visitAttribute (http://localhost:3000/packages/blaze.js?58873cae0cd397939e96493c52ed6101c0a04744:1924:62) at HTML.TransformingVisitor.def.visitAttributes (http://localhost:3000/packages/htmljs.js?fcf2660be84fbc0c33b97ee8932dbd46612f3566:226:44) at Blaze.HTMLJSExpander.def.visitAttributes (http://localhost:3000/packages/blaze.js?58873cae0cd397939e96493c52ed6101c0a04744:1916:63) at Object.Blaze._expandAttributes (http://localhost:3000/packages/blaze.js?58873cae0cd397939e96493c52ed6101c0a04744:1938:32)

[David Greenspan]

Vincent,

I need to know more than that.  Can you link to a reproduction, or at least provide more context?

-- David

--

[Vincent Jaubert]

Since the error is rather cryptic (at least for me) i can't provide more information as i have no idea about what is causing that.

The good news is that the performance regression which was impacting my app with version 0.8.x has been fixed, on my testing app the performances are on par with 0.7.2 !

[David Greenspan]

Hi Vincent,

About the performance, that's great!

The problem is something to do with updating an HTML tag attribute, most likely due to the template being compiled incorrectly.  Can you set a breakpoint in Blaze._expandAttributes and inspect `attrs` to see what it is?  This might tell you what part of what template is causing the error.  It's probably an attribute with template tags in it of some sort.

Thanks,

David

[David Greenspan]

Hi Chris,

You're right.  It looks like we weren't properly isolating data argument changes so that they don't cause content re-renders, probably extending to #with as well.  The implementation of view.lookup was taking dependencies, while the template compiler was assuming that view.lookup("..") or view.lookup("foo") would return a function if there were any reactivity.

I've committed a fix to devel, not properly tested yet but I wanted to see if this fixes your problem.

The reason that I didn't implement returning Views from inclusion functions is that doing so would lose the isolation benefit of returning Templates.  Inclusion functions are re-run pretty liberally (any time the data context or any argument changes), so the fact that they must return a template like "Template.foo" is important because then we can compare the new return value to the old return value, and not recreate the View if it's the same as before (Template.foo === Template.foo).  You may be able to take advantage of this same behavior yourself by calling Template.__create__ once per "template" and then using the result from inclusion functions.

-- David

On Thu, Jul 10, 2014 at 8:06 PM, Chris Mather <ch...@eventedmind.com> wrote:

[David Greenspan]

Vincent,

Also, try your code again on devel now that I've fixed Chris's issue.

Thanks,

David

[Chris Mather]

You're too fast David! I got excited with my drawing tablet to illustrate the issue (attached) :-). I'll take a look at devel now.

[David Greenspan]

At some point we'll have a "real" solution to the problem of inclusion argument reactivity.  Right now we're getting by using templates, with the help of UI.dynamic. :)

[Vincent Jaubert]

Bad news: your patch doesn't fix my commit.
I have watched the value of "attrs" in Blaze._expandAttributes (attrs, parentView)

I believe that before the crash, attrs is an object, with two keys. The first key is a regular html id ("post_message" string). The second key is named "value" but contains an array of length 3.

Content of the array is :

1. value: Array[3]
1. 0: "↵ "
2. 1: Blaze.View
3. 2: "↵↵ "
4. length: 3

The corresponding code in my template is just

    <textarea id="post_message"></textarea>

AFAIK, there is no logic (no spacebars tags) enclosing it. 
I'm using Bootstrap 3, which could somehow modify the textarea. 

[Vincent Jaubert]

Le vendredi 11 juillet 2014 18:39:15 UTC+2, Vincent Jaubert a écrit :

Bad news: your patch doesn't fix my commit.

Doesn't fix my problem 

[David Greenspan]

A textarea bug.  Sweet, thanks for doing that!

--

[Andrew Mao]

I used UI.emboxValue a lot to help calm reactive functions in APIs when it wasn't immediately clear how to optimize something and I wanted to return to it later.

What can I use now that it's gone?

[David Greenspan]

Hi Andrew, can you give an example?

On Friday, July 11, 2014, Andrew Mao <miz...@gmail.com> wrote:

I used UI.emboxValue a lot to help calm reactive functions in APIs when it wasn't immediately clear how to optimize something and I wanted to return to it later.

What can I use now that it's gone?

--

[Vincent Jaubert]

Hi everyone,

today, with latest commits, i got a bug i had not yesterday. I think it's a regression.

I got this error

Exception in template helper: Error: $regex has to be a string or RegExp at Error (<anonymous>) at Object.ELEMENT_OPERATORS.$regex.compileElementSelector (http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1909:15) at http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1533:19 at Function._.each._.forEach (http://localhost:3000/packages/underscore.js?0a80a8623e1b40b5df5a05582f288ddd586eaa18:164:22) at operatorBranchedMatcher (http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1513:5) at compileValueSelector (http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1425:12) at http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1404:9 at Function._.each._.forEach (http://localhost:3000/packages/underscore.js?0a80a8623e1b40b5df5a05582f288ddd586eaa18:164:22) at compileDocumentSelector (http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1387:5) at _.extend._compileSelector (http://localhost:3000/packages/minimongo.js?6aa0e153bfd7e4a28ee447a4cbfaf1fef0870a06:1364:12)

Again, i have no idea from where it's coming from so any pointer to find further info is welcomed.

[Vincent Jaubert]

Nevermind, it's also happening sometimes with 0.8.2. Sorry for wrong report.

[David Greenspan]

Hi Vincent,

I just committed a change on devel that should prevent the crash, but I can't for the life of me see how a textarea would have those contents, especially if there are none in the template!  Are you using Jade, or doing anything fancy with how templates are generated?

The Spacebars compiler transforms the contents of a <textarea> tag into an attribute called "value," so that it can be treated the way attributes are treated at runtime.  If "value" is reactive (e.g. contains a Blaze.View), it should be wrapped in a function by the compiler and not be an array (which is causing the crash).  Additionally, the "value" array you are seeing contains realistic whitespace that could only have come from a template, maybe a template like this:

```

    <textarea id="post_message">

        {{something}}

    </textarea>

```

Bootstrap modifying the textarea element at runtime would not have the same effect.

-- David

--

[Vincent Jaubert]

Le dimanche 13 juillet 2014 20:44:32 UTC+2, David Greenspan a écrit :

I just committed a change on devel that should prevent the crash,

Ok, no crash anymore, thank you.

 

but I can't for the life of me see how a textarea would have those contents, especially if there are none in the template!  Are you using Jade, or doing anything fancy with how templates are generated?

David, i think this is becoming interesting. I double checked to see if there was something modifying the textarea somewhere i was not remembering. The only thing i found is a t.find("#post_message").value="";  which i use to clear the textarea somewhere else, but i checked, it's never called.

The thing i found REALLY interesting, is that when i run my app with the devel branch, the empty textarea seems indeed to be filled with some space or end of line content after display. When i click on it the cursor show on the middle of the textarea. When i run 0.8.2, the textarea shows up really empty, and the cursor appears on top left side when i click on the textarea.
I'm not using anything special outside Bootstrap-3. I m not using any filler in the textarea, like i said only a pure <textarea id="post_message"></textarea>
I hope that helps.

[David Greenspan]

Very interesting indeed!

Can you set a breakpoint at the exception ("Can't render the same View twice" in Blaze._expandView) -- er, by checking out the commit when it was still thrown -- and send me the result of ` Blaze.getCurrentTemplateView().render.toString() `?  That should print the compiled source code of the template and shed light on how we might be getting a "value" attribute on that textarea.

Thanks,

David

[Vincent Jaubert]

Ok, the end of line happens to end in the value area because of a missing closing parenthesis

HTML.TEXTAREA({

        id: "post_message"

    }, "\n        ",

BUT, when you look at the code, there is the right number of parentheses, but the nesting of tags seems to be incorrect (as far as i understand it).
There seems to ben an #each block inserted in the middle of the textarea in the compiled version. When looking at the html template, i don't see a problem there, but there is probably one.
I fear you will have to dive in my code. Here it is:

Raw of the render.toString():

function () { var view = this; return [ HTML.DIV({ id: "messages" }, "\n ", Blaze.Each(function() { return Spacebars.call(view.lookup("threads")); }, function() { return [ "\n ", HTML.DIV({ "class": "message", id: function() { return Spacebars.mustache(view.lookup("_id")); } }, "\n ", Blaze.If(function() { return Spacebars.call(view.lookup("isDoctor")); }, function() { return [ "\n ", HTML.DIV({ "class": "archive_link" }, "Archiver"), "\n " ]; }), "\n ", Blaze.Each(function() { return Spacebars.call(view.lookup("messages")); }, function() { return [ "\n ", Spacebars.include(view.lookupTemplate("message")), "\n\n " ]; }), "\n ", Blaze.Unless(function() { return Spacebars.call(view.lookup("isResponding")); }, function() { return [ "\n ", HTML.SPAN({ "class": "reply_link" }, "Répondre"), "\n " ]; }), "\n ", Blaze.If(function() { return Spacebars.call(view.lookup("isResponding")); }, function() { return [ "\n ", HTML.TEXTAREA({ id: "textarea_reply_message" }), "\n ", HTML.DIV({ id: "send_reply_link" }, "Envoyer"), "\n " ]; }), "\n\n "), "\n " ]; }), "\n\n "), "\n ", HTML.TEXTAREA({ id: "post_message" }, "\n ", Blaze.Each(function() { return Spacebars.call(view.lookup("threads")); }, function() { return [ "\n ", HTML.DIV({ "class": "message", id: function() { return Spacebars.mustache(view.lookup("_id")); } }, "\n ", Blaze.If(function() { return Spacebars.call(view.lookup("isDoctor")); }, function() { return [ "\n ", HTML.DIV({ "class": "archive_link" }, "Archiver"), "\n " ]; }), "\n ", Blaze.Each(function() { return Spacebars.call(view.lookup("messages")); }, function() { return [ "\n ", Spacebars.include(view.lookupTemplate("message")), "\n\n " ]; }), "\n ", Blaze.Unless(function() { return Spacebars.call(view.lookup("isResponding")); }, function() { return [ "\n ", HTML.SPAN({ "class": "reply_link" }, "Répondre"), "\n " ]; }), "\n ", Blaze.If(function() { return Spacebars.call(view.lookup("isResponding")); }, function() { return [ "\n ", HTML.TEXTAREA({ id: "textarea_reply_message" }), "\n ", HTML.DIV({ id: "send_reply_link" }, "Envoyer"), "\n " ]; }), "\n\n "), "\n " ]; }), "\n\n "), HTML.Raw('\n <input type="button" id="button_post_message" value="Envoi">') ]; }

HTML Template

<template name="messages">

    <div id="messages">

        {{#each threads}}

            <div class="message" id="{{_id}}">

                {{#if isDoctor}}

                    <div class="archive_link">Archiver</div>

                {{/if}}

                {{#each messages}}

                    {{>message}}

                {{/each}}

                {{#unless isResponding}}

                    <span class="reply_link">Répondre</span>

                {{/unless}}

                {{#if isResponding}}

                    <textarea id="textarea_reply_message"></textarea>

                    <div id="send_reply_link">Envoyer</div>

                {{/if}}

            </div>

        {{/each}}

    </div>

    <textarea id="post_message"></textarea>

    <input type="button" id="button_post_message" value="Envoi"/>

</template>

The #each threads block has nothing to do with the textarea at the end of the template, but somewhow ends up in the middle of it.

Good luck !

[David Greenspan]

You win the prize for weirdest bug! :P  I'll see if I can reproduce it.

Thanks,

David

--

[Andrew Mao]

As of the current commit on devel, the spacebars compiler is throwing the following error 

 While building package `autocomplete`:

<runJavaScript-37>:506:18: Cannot read property 'length' of null (compiling inputs.html)

  at HTMLTag (<runJavaScript-37>:506:18)

  at HTMLTools.Parse.getContent (<runJavaScript-38>:3379:41)

  at Object.HTMLTools.parseFragment (<runJavaScript-38>:3231:14)

  at Object.SpacebarsCompiler.parse (<runJavaScript-41>:1047:24)

  at Object.SpacebarsCompiler.compile (<runJavaScript-41>:1055:32)

  at Object.html_scanner._handleTag (<runJavaScript-42>:174:48)

  at Object.html_scanner.scan (<runJavaScript-42>:118:20)

  at doHTMLScanning (<runJavaScript-42>:241:31)

  at Package (<runJavaScript-42>:282:5)

on this file: https://github.com/mizzao/meteor-autocomplete/blob/master/inputs.html

Of course, that package needs to be updated for it to fully work, but I can't update it if it doesn't compile...

[David Greenspan]

Andrew, try now on devel.

Vincent, try too.  If fixing Andrew's bug doesn't fix yours, I'll take another look tomorrow afternoon, but the next thing I will probably ask you to do is one of:  1) Give me access to the app, 2) Create a minimal reproduction, or 3) determine which git commit created the problem, via some sort of bisection.

Thanks,

David

--

[David Greenspan]

Vincent, I fixed your case in this commit: https://github.com/meteor/meteor/commit/ab9cae612332a52feb9866de3979221a50faf3f7

What happened here is we only changed a few lines of code in the HTML parser, having to do with textareas, to accommodate the new rendering model with Blaze.View, but I wasn't careful enough with the change.  Usually unit tests catch such basic errors, and we do have tests of textareas specifically, but not sufficiently advanced ones.  None of the tests have textarea tags with dynamic attributes (Andrew's case), or textareas that come after other elements (Vincent's case).  So I'll write some more tests.

Thanks for working with me on this!

-- David

[Andrew Mao]

Hi David,

My code runs now on devel, however it's still somewhat far from debugging because (1) I need to jump through some hoops to get IR working and (2) I need a replacement for UI.emboxValue.

You asked for an example of this before. Here are some. It's kind of crappy that a non-underscored method went away :(

I have a client API function that might recompute more often than necessary. I wrap this up so it only recomputes once per change, and can be further optimized later:

# Find current round, whether running or in break

# TODO this polls every second, which can be quite inefficient

currentRound = ->

  if (activeRound = RoundTimers.findOne(active: true))?

    # Is the active round started?

    if activeRound.startTime <= TimeSync.serverTime()

      return activeRound

    else

      # Return the round before this one, if any

      return RoundTimers.findOne(index: activeRound.index - 1)

  return

TurkServer.currentRound = UI.emboxValue(currentRound, EJSON.equals)

I have a function that will contain the same value across a recomputation, but obtained through a different method of calculation. I don't want to trigger a reactive update unless the actual value changes:

  # Milliseconds this user has been idle in the experiment

  @idleTime: UI.emboxValue ->

    return unless (instance = _currentAssignmentInstance())?

    return _idleTime(instance, TimeSync.serverTime())

Stuff like that. It can all be replaced, but I'm just wondering what you use now instead of emboxValue.

[David Greenspan]

Hi Andrew,

Sorry for making UI.emboxValue look legit and then removing it.

Others can chime in with what they do for cases like this -- I'm sure some have their own utility functions.

In Blaze, we tend to use a Deps.autorun that sets a Blaze.ReactiveVar.  Then to read the value, we call "get" on the ReactiveVar.  If the autorun has a finite lifecycle (i.e. if it needs to be stopped), we use a view.autorun.  The constructor of Blaze.ReactiveVar takes an equalsFunc.

UI.emboxValue was supposed to encapsulate this pattern, and additionally to not require that the autorun be stopped; it would be started and stopped automatically based on demand for the value.  Unfortunately, it was difficult to reason about when or how often the emboxed function would be called, and in what context, which is important for template helpers.  Also, in some cases the emboxValue did have to be stopped explicitly anyway!

So we use the autorun-Var pattern because it's easy to understand and reason about, and it leads to minimal extra function calls as long as the autorun gets stopped if necessary.  Here's a function that sets up a global autorun and returns a getter for the ReactiveVar:

```

embox = function (f, equalsFunc) {

  var v = null; // ReactiveVar

  Deps.autorun(function (c) { // runs forever...

    var newValue = f();

    if (c.firstRun) {

      // By passing the first value into the constructor,

      // we avoid ever calling equalsFunc(undefined, ...)

      // on the first value.

      v = Blaze.ReactiveVar(newValue, equalsFunc);

    } else {

      v.set(newValue);

    }

  });

  return function () {

    return v.get();

  };

};

```

Example of use:

```

var emboxedSomething = embox(calculateSomething);

Deps.autorun(function () {

  console.log(emboxedSomething());

});

```

If you don't care how many times the underlying function is evaluated, you can also create the autorun-Var on the fly, such that they will absorb "fake" changes until a real change comes along, at which point they are torn down:

```

absorb = function (f, equalsFunc) {

  if (! Deps.active)

    return f();

  var v = null; // ReactiveVar

  Deps.autorun(function (c) {

    var newValue = f();

    if (c.firstRun) {

      // By passing the first value into the constructor,

      // we avoid ever calling equalsFunc(undefined, ...)

      // on the first value.

      v = Blaze.ReactiveVar(newValue, equalsFunc);

    } else {

      v.set(newValue);

    }

  });

  // If v ever changes according to equalsFunc, the

  // Computation we're in right now will be invalidated

  // and the autorun above will be stopped.

  return v.get();

};

```

Example of use:

```

Deps.autorun(function () {

  console.log(absorb(function () {

    return calculateSomething();

  }));

});

```

Hope this helps.

-- David

[Vincent Jaubert]

Le mardi 15 juillet 2014 05:10:48 UTC+2, David Greenspan a écrit :

Thanks for working with me on this!

Thank you David, it works.  

[Andrew Mao]

Hi David,

Will some docs appear for how to attach events to the lifecycle of a template?

For example, I mentioned before that I'd spin off a one-time UI.Component for a given template in order to trick the `rendered` and `destroyed` callbacks to be called every time the data changed. As you pointed out, I didn't care if the DOM elements were lost (trying to imitate Spark rendering behavior), but now maybe I can implement something that properly re-uses the contents of the template.

Thanks,

Andrew

[Andrew Mao]

I'm seeing this error:

Exception from Deps recompute function: Error: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node. at Error (native) at DOMRange.detach (http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:452:24) at DOMRange.setMembers (http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:411:12) at doMaterialize (http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:1838:22) at Object.Deps.nonreactive (http://192.168.56.101:3000/packages/deps.js?d9b2b2601bdab0f57291b38e7974a7190b8aac01:382:12) at doRender (http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:1829:12) at http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:1774:16 at Object.Blaze.withCurrentView (http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:2000:12) at viewAutorun (http://192.168.56.101:3000/packages/blaze.js?0f217b7709a292b21472d8707009c2cd87a1ae25:1773:18) at Deps.Computation._compute (http://192.168.56.101:3000/packages/deps.js?d9b2b2601bdab0f57291b38e7974a7190b8aac01:214:36)

...when changing the value of `selectedBatch` (a document in a collection) for this template: https://github.com/HarvardEconCS/turkserver-meteor/blob/master/admin/experimentAdmin.html#L203

The template re-renders as normal though, and one wouldn't notice without the console open.

[Andrew Mao]

0.8.3-rc2 seems to have fixed this error.

[Pascal Richier]

0.8.3-rc1 seem to have fixed Dom Leak issue:

https://github.com/meteor/meteor/issues/2212#issuecomment-47239741

[David Greenspan]

Hi Andrew,

I'm not completely sure what you're asking here; maybe it's just a matter of terminology.  The created/rendered/destroyed callbacks are how you get notified about the lifecycle of a template.  Can you remind me what the behavior you're trying to get is?

Thanks,

David

--

[Andrew Mao]

Hi David,

In my post a while ago, I pointed out that I wanted to take some actions in the template in response to data being updated.

One way that I did this was to create a new UI.Component for every render, in Blaze pre-refactor. This would render a template with the rendered and destroyed callbacks being triggered for each data change, similar to the behavior in Spark.

Obviously, that is a little overkill and doesn't preserve the DOM. So what is a better way to do this, and to catch updates to just the data fields that I care about? I'm going to try and figure out if Blaze.View.autorun or Blaze.ReactiveVar is what I'm looking for, but maybe some pointers would be useful.

[Andrew Mao]

Maybe just something more basic first - what is the right way to create a new Blaze.View for a component as part of a package? Before, templates were UI.Components. However, helpers that return a new Blaze.View right now throw errors. If we want to write a custom component that gets access to all the Blaze.View goodies, how do we make that available as a template?

[Chris Mather]

Hi Andrew,

I've been working with Blaze.View quite a bit lately as part of the next-gen iron-router project (refactor branch of iron-router). You might be interested in some of the underlying packages that use Blaze.View; in particular iron-dynamic-template: https://github.com/EventedMind/iron-dynamic-template/tree/packaging

Then you might also check out a Controller implementation that uses dynamic templates: https://github.com/EventedMind/iron-controller

And a Guide on how to access the controller from a template helper and use reactive state variables: http://eventedmind.github.io/iron-router/#accessing-the-current-route-controller

I'd love to improve on any of the patterns I used, especially in DynamicTemplate.

Chris

[Chris Mather]

Also, an example of using a class like Iron.Layout from a UI helper:

https://github.com/EventedMind/iron-layout/blob/packaging/layout.js#L379

[Andrew Mao]

Ah, thanks a lot. I totally forgot about Chris to the rescue. He always documents and provides examples for new Meteor tidbits before official docs are even available :)

[Andrew Mao]

Perfect. I was looking for Template.__create__ in https://github.com/meteor/meteor/blob/devel/packages/templating/templating.js#L156.

[Andrew Mao]

Just for clarification: Blaze.Views clean themselves (their autorun computations) up recursively, right? So we don't have to manually Blaze.destroyView() for views that we create for components...or do we?

[David Greenspan]

Blaze.Views clean themselves up recursively.

I've fallen a little behind in this thread, but you may want to look into Blaze.getCurrentData() (which is reactive) and using `this.__view__.autorun(...)` from "created" and "rendered" callbacks -- until we have something better.

-- David

[Chris Mather]

It's possible iron:layout is being overzealous in cleaning up regions. I think I call destroy() on each region if we're about to change the layout completely. It might not be necessary.

[Andrew Mao]

Took me a couple of hours, but I think I figured it out, and it's working sublime-ly. http://documents.meteor.com/ shows how different documents and different editors can be switched between without the old Spark-style rendering I was using before.

A few quick questions:

• If a view is rendering a template, do I always need to create it using a Blaze.With for the template to get data? It doesn't just get the data directly? https://github.com/mizzao/meteor-sharejs/blob/blaze-refactor/sharejs-client.coffee#L93
  
• Also to be clear about the above, this view that is being created will clean itself up when rendered by another view, right? So I don't need https://github.com/mizzao/meteor-sharejs/blob/blaze-refactor/sharejs-client.coffee#L85

Finally, there is no need to manually clean up anything about a Blaze.ReactiveVar, as long as all computations that have a handle on it get stopped - is that right?

Thanks,

Andrew

[Andrew Mao]

Hi Chris,

Yes, that appears be true. I verified that the child view I created with the Template helper is destroyed in the onDestroyed callback of the parent view.

[Andrew Mao]

Hi David,

I found a couple more bugs for you while updating https://github.com/mizzao/meteor-autocomplete.

See https://github.com/mizzao/blaze-refactor-textarea.

First, {{> UI.contentBlock}} inside a textarea triggers the following error:

1. Uncaught Error: Illegal HTML attribute name: 0 html.js:616
1. HTML.flattenAttributeshtml.js:616
2. updateAttributesmaterializer.js:69
3. (anonymous function)view.js:142
4. Blaze.withCurrentViewview.js:368
5. viewAutorunview.js:141
6. Deps.Computation._computedeps.js:181
7. Deps.Computationdeps.js:115
8. Deps.autorundeps.js:329
9. Blaze.View.autorunview.js:140
10. Blaze.DOMMaterializer.def.visitTagmaterializer.js:80
11. HTML.Visitor.def.visitvisitors.js:46
12. doMaterializeview.js:199
13. Deps.nonreactivedeps.js:349
14. doRender

Second, take out the {{> UI.contentBlock}}: hash arguments no longer seemed to be passed into block helpers. See /blaze-refactor-textarea.html. The textarea should render with <textarea id="bar"> but renders with nothing. It's possible this may have broken sometime between 0.8.0 and 0.8.2 but I just noticed it now.

Finally (not a bug) perhaps you could take a quick look at https://github.com/mizzao/meteor-autocomplete/blob/blaze-refactor/templates.coffee. I have an object that handles processing and matching of multiple autocompletion rules that I need to attach to event handlers in templates. In particular, I did something very wonky to get a template instance from a view (double underscores!) and I was wondering if you had any better suggestions.

Thanks!

[Maxime Quandalle]

David,

For testing the `jade` package, I use a spacebars template and an equivalent jade template and I check if they both compile to the same js code.
Currently I encounter a lot of test errors due to the following non-optimization:

- fail — string_equal - expected

function () {
  var view = this;

  return HTML.P("Hello ", Blaze.View(function() {
    return Spacebars.makeRaw(Spacebars.mustache(view.lookup("world")));
  }));
}

- actual

function () {
  var view = this;

  return HTML.P([ "Hello ", Blaze.View(function() {
    return Spacebars.makeRaw(Spacebars.mustache(view.lookup("world")));
  }) ]);
}

Could the spacebars compiler optimize arrays so that third-party compilers, like jade, don't have to "beautify" their AST?

Maxime

Le jeudi 10 juillet 2014 00:53:56 UTC+2, David Greenspan a écrit :

Hi everyone,

We've just completed a refactor of Blaze which preserves the public API but simplifies the internals, in order to address technical debt from the 0.8 release and make Blaze a comprehensible and lasting library that can serve as a solid foundation for what's to come.

Please test your apps and packages on the "blaze-refactor" branch.  It’s entering QA and will be released in a couple weeks or so.  Now is the time to port your packages and give us any feedback.

Note that most apps and packages will not have to change at all.  Even the latest and experimental APIs are the same, like UI.dynamic and _uihooks.  UI.render is now joined by the new UI.remove.

Let us know if you have any questions or trouble with your code!

Technical Details:  I know a number of you have been digging under the hood of Blaze for a while, and have discovered UI.Component and the Component tree.  This "Component API" didn't provide a full-fledged modular UI system; it's usefulness lay in exposing the view tree in a concrete way.  That's why we've slimmed down UI.Component and refashioned it into Blaze.View.  The View tree replaces the Component tree.  If you've hooked into Blaze at the Component level at all -- which we've kept very quiet about -- you'll almost certainly find a way to do the same thing with Views.  I look forward to talking more about Views and why they are cool in the coming weeks.  We still plan to develop patterns for forms and component classes as part of core, but they are on the post-1.0 roadmap.

Thanks,

David

[David Greenspan]

Hi Maxime,

Sounds reasonable, although the window for 0.8.3 is closing.  Is this a new thing?

-- David

[Andrew Mao]

David, were the two bugs I reported clear enough?

I'm hoping they can be fixed for 0.8.3 as well.

[David Greenspan]

Hi Andrew, what two bugs do you mean?

Thanks,

David

On Thursday, July 24, 2014, Andrew Mao <miz...@gmail.com> wrote:

David, were the two bugs I reported clear enough?

I'm hoping they can be fixed for 0.8.3 as well.

--

[Maxime Quandalle]

No, this behavior exists since the beginning of the Blaze epoch.

[Andrew Mao]

Several posts ago that I pointed out in https://github.com/mizzao/blaze-refactor-textarea.

1. {{> UI.contentBlock}} throws an error when used inside a textarea (used to work in 0.8.2)

2. hash arguments not passed to block helpers (may have broken sometime between 0.8.0 and 0.8.3)

Please see the original post https://groups.google.com/d/msg/meteor-core/DucHmVXjayg/3BH75PlsW2UJ and let me know if you have any questions.

On Friday, July 25, 2014 3:08:25 AM UTC-4, David Greenspan wrote:

Hi Andrew, what two bugs do you mean?

Thanks,

David

On Thursday, July 24, 2014, Andrew Mao <miz...@gmail.com> wrote:

David, were the two bugs I reported clear enough?

I'm hoping they can be fixed for 0.8.3 as well.

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core+unsubscribe@googlegroups.com.

[Andrew Mao]

David, I summarized the problems in https://github.com/meteor/meteor/issues/2338 and https://github.com/meteor/meteor/issues/2339.

Also, https://github.com/meteor/meteor/issues/2337 is something that would be good to fix as well.

[Fabian Vogelsteller]

It would be nice if "Blaze.getCurrentView()" would also work from inside the templates events.

I try to improve my TemplateSession helper.

Which works like session but bound to template instances. So far it would works well, just not inside events. (I know the template instance is available as argument, but making getCurrentView() work would allow for a unified API of the package, across template helpers, callbacks and events)

So far the memory etc of the new Blaze looks amazing (It also works very well with polymer components, reactively, i'm very impressed)

[David Greenspan]

Hi Maxime,

I misunderstood at first.  It sounds like the extra array brackets are from an array you are creating in your code.  You should modify your code to strip out, or not generate, the array.

-- David

On Fri, Jul 25, 2014 at 3:54 AM, Maxime Quandalle <maxime.q...@gmail.com> wrote:

No, this behavior exists since the beginning of the Blaze epoch.

[David Greenspan]

Fabian,

Good call, the fix (for getCurrentView in event handlers) is on the release-0.8.3 branch and will go into that release.

Thanks for the compliment!

-- David

--

[John Baylor]

Fabian,

How are you getting meteor to work with polymer? whenever I try "mrt add polymer" I get an updated (and now broken) smart.json file and a bunch of error messages:

smart.json changed.. installing from smart.json

✓ polymer

    tag: https://github.com/andrewreedy/meteor-polymer.git#v0.0.2

ERROR: 1 Command failed: error: pathspec 'v0.0.2' did not match any file(s) known to git.

STDOUT:  

STDERR: error: pathspec 'v0.0.2' did not match any file(s) known to git. 

/usr/local/lib/node_modules/meteorite/lib/sources/git.js:181

            self.checkoutType + ": " + (self.commit || self.head);                                     ^

There was a problem checking out tag: v0.0.2

And this breaks any future use of "mrt" until I manually edit smart.json and remove the polymer section. 

So how did you get polymer working with meteor? By somehow using a different package or by rolling your own integration?

thanks,

JB

On Fri, Jul 25, 2014 at 10:32 AM, Fabian Vogelsteller <fabian.vo...@googlemail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

--

https://twitter.com/JohnB
http://github.com/JohnB

http://johnb.github.io/

[Fabian Vogelsteller]

Hey john,

I use the following package:

https://github.com/ecwyne/meteor-polymer

It works well chrome, the safari polyfill doesn't seem to load correctly. I guess the platform.js has to be executed, every time there is a template rendered, but i didn't figured this one out yet.

[John Baylor]

Worked great! A few lines of code and I had a google map polymer object working.

Thanks,

JB

--

You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[ega radiegtya]

I got this error when updating to meteor 0.8.3. I think it was because I have my own public helper class (not an atmosphere plugin). Any idea? thanks

Exception from Deps recompute function: Error: No such function: error at http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:2494:15 at Spacebars.call (http://localhost:3000/packages/spacebars.js?8717c3bee1160f47e7a46ea4e1bd0796f944cad8:169:18) at Spacebars.mustacheImpl (http://localhost:3000/packages/spacebars.js?8717c3bee1160f47e7a46ea4e1bd0796f944cad8:106:25) at Object.Spacebars.dataMustache (http://localhost:3000/packages/spacebars.js?8717c3bee1160f47e7a46ea4e1bd0796f944cad8:138:39) at http://localhost:3000/client/views/billing/medicalRecords/template.index.js?ccf7c493b6ad07aca4f27520382ac14aaaa8bd3c:21:26 at null.<anonymous> (http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:2275:44) at http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:1805:16 at Object.Blaze.withCurrentView (http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:2038:12) at viewAutorun (http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:1804:18) at Deps.Computation._compute (http://localhost:3000/packages/deps.js?d9b2b2601bdab0f57291b38e7974a7190b8aac01:214:36) debug.js:41

Exception from Deps recompute function: Error: No such function: error at http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:2494:15 at Spacebars.call (http://localhost:3000/packages/spacebars.js?8717c3bee1160f47e7a46ea4e1bd0796f944cad8:169:18) at Spacebars.mustacheImpl (http://localhost:3000/packages/spacebars.js?8717c3bee1160f47e7a46ea4e1bd0796f944cad8:106:25) at Object.Spacebars.dataMustache (http://localhost:3000/packages/spacebars.js?8717c3bee1160f47e7a46ea4e1bd0796f944cad8:138:39) at http://localhost:3000/client/views/billing/medicalRecords/template.history.js?e0799a940b358cf6e0457dc7df4eb8995e76674b:26:26 at null.<anonymous> (http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:2275:44) at http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:1805:16 at Object.Blaze.withCurrentView (http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:2038:12) at viewAutorun (http://localhost:3000/packages/blaze.js?309c2a3b573dca998c07c493ba4953d451b2c963:1804:18) at Deps.Computation._compute (http://localhost:3000/packages/deps.js?d9b2b2601bdab0f57291b38e7974a7190b8aac01:214:36)

debug.js:41 

[David Greenspan]

Do you define a helper "error"?  How?

--

[ega radiegtya]

Yes, and that has been solved anyway. And it was my mistake. 

I don't know if in this version the html and js template will be very strict. 

for example if i had define a helper named

Template.templateName.helpers({

   blah: function(){

       return "something"

   }

})

and then in the html view 

{{blah}} <!-- it should work -->

{{someUndefinedFunctionFromTemplate}} <!-- in meteor 0.8.3 this is not working anymore if undefined in template (0.8.2 work) -->

=========================================================================================================================

But I got another error, here's the code

//if i console.log this it will print null -> null -> null -> then if ready it will correctly get the value "outpatientRegistration value" (it's normal, same with 0.8.2)

var outpatientRegistrationId = this.getOutpatientRegistrationId(); 

//but i got error in this line in version 0.8.3 (btw it's working perfectly in meteor 0.8.2)

if (outpatientRegistrationId)

            var patientId = Billing.OutpatientRegistrations.findOne(outpatientRegistrationId).patientId;     

Error Message:

Exception from Deps recompute function: TypeError: Cannot read property 'patientId' of undefined               

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/DucHmVXjayg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.

[David Greenspan]

> {{someUndefinedFunctionFromTemplate}}

This works for me, unless I try to give it arguments (like {{someUndefinedFunctionFromTemplate "blah"}}).  I don't think that's new, though.

> Cannot read property 'patientId' of undefined

I can't tell much more than you would probably be able to deduce from the code given.  It looks like `this.getOutpatientRegistrationId()` starts returning non-null before `findOne` returns non-null (i.e. before the object is in minimongo).  A quick solution might be to put the result of the findOne in a variable and also test whether that is defined.

-- David

[ega radiegtya]

yes I have doing what you told. Yeah there is no error, but screen not showing the data, only loading (atmosphere spin loading) then white screen without error.

I don't know what's going on. 

[Helder Luz]

Pre 0.8.3, this worked ok when creating a new "templateX" template programatically:

      var compiled = Spacebars.compile(templateText); 

      var renderer = eval(compiled);

      Template["templateX"] = UI.Component.extend({

        kind: "dynamicTemplate",

        render: renderer

      });

What is the best way to do the same post 0.8.3?

[Helder Luz]

Got it! Please ignore it... 

[Gadi Cohen]

Hi All

Sorry, I'm joining the party quite late this year; had a lot of other big commitments around this time.  I found it quite difficult to jump on board and constantly refer to difference posts in this thread, source code comments, etc, as I needed them, so once again I've attempted to make a summary with the most important points here:

http://www.meteorpedia.com/read/New_Blaze_API

to be used by early adopters until official documentation is available.  I would love the early pioneers and of course, David & Avital, to take a look and see if everything looks good... and of course, like last time, the community is invited to improve on this, add other useful patterns, etc.

From my side, I'm sure I'll have more to add as I work to upgrade "famous-components" to "famous-views" over the weekend :)  Very excited about the clearer API and much better control over reactivity, which lend themselves to some very exciting improvements in the package.

Gadi