Dispatches From the Edge: Automatic Transitions and SC.View Optimizations

written by Tyler Keating

Comments Off

Version 1.10 is shaping up to be a fundamental advancement of SproutCore as the best framework for creating powerful user experiences on the web.  We’ve already been doing the best of breed practices for creating dynamic web applications for some time.  For example, running in the client, maintaining the application “truth” in code, minimizing touching the DOM and many other practices that keep SproutCore apps as fast as possible.  These features allow you to create extremely complex interfaces that update instantly as the user interacts with them.  However, while instant updates were a major advancement, they can give the interface a jarring feel and therefore the next level of application design is to go beyond instant updates and add “life” or “play” to your user interface with subtle transitions.

As such, SproutCore 1.10 will include a new automatic transition architecture that is so easy to use, developers can actually play around with complex transitions while first implementing a view rather than needing to commit more time to it later.  To do so, you simply specify a transition plugin to use during one of the four state changes: appending, becoming visible, becoming hidden and removing.  To make it even easier, SproutCore includes a few built-in transition plugins: SC.View.FADE, SC.View.MOVE, SC.View.BOUNCE, SC.View.SPRING and SC.View.SCALE and it’s very easy to write your own transition plugins to do any type of advanced animation based on the SC.Transition protocol.

Continue reading

Dispatches From the Edge: Super Fast Collections

written by Tyler Keating

Comments Off

One of the most advanced changes coming in 1.10 is the formalization of a major enhancement to SproutCore’s collection views.  Some of you may have heard of, used or tried to use the SC.CollectionFastPath mixin which gives SproutCore’s collection views, namely SC.ListView and SC.GridView, a massive performance boost.  The performance boost comes from pooling the item view objects, pooling item view layers (i.e. elements) and re-positioning layers using layout styles without modifying the DOM tree.  By re-using objects and elements, we can increase the speed that our collections can update, making gigantic lists perform like butter, even on mobile.

However, using SC.CollectionFastPath was unwieldy and difficult to get working correctly.  Turning it on was not enough, you also had to provide a couple properties on your item view class that were totally undocumented.   Due to the fact that SC.CollectionView is already optimized to create item view objects and layers only for the visible portion of the collection, it could be hard to even be sure that the fast path code was active or not.  This is all changing in 1.10.

We believe that every SproutCore view should be as fast as possible out-of-the-box on every platform and so we’re making these improvements a part of SC.CollectionView directly.  This means that by default, SC.ListView and SC.GridView will be fully optimized without any further configuration.  That said, when creating custom item views, you should properly support render and update.  Since view performance is so important, you should already know how to do this and if you need a good example, check out the custom item views in the new demo in the SproutCore Showcase.  This demo was created to debug this new technology as well as to demonstrate working with gigantic lists.

For now, the feature is still being tested and fine-tuned and any additional real-world feedback is appreciated.  So please check it out on the SproutCore master branch and bring any issues forward so that they can be addressed before release.

Thanks!

 

For discussion, please use sproutcore@googlegroups.com or #sproutcore on IRC.

Note:  Whereas, before you needed to set properties to turn this on, you have to set properties to turn it off right now.  If for whatever reason, you don’t want to pool elements, you can set isLayerReusable to false on your custom item view and if you don’t want to pool views, you can set isReusable to false as well.

Dispatches From the Edge: Invoking “Next”

written by Tyler Keating

Comments Off

As the 1.10 release nears completion, I thought I’d better start writing about some of the many improvements now, lest the final release blog post would take me two days to write.  A lot of the changes, including today’s topic, were the result of working on big feature additions and discovering that more support was needed closer to the core.  Which brings me to the topic of this post:  SC.RunLoop.prototype.invokeNext. Continue reading

Dispatch From The Edge: Blacklists and Whitelists

written by Greg Moeck

2 Comments

The “true edge” of SproutCore nowadays is primarily the 2.0 branch, where the new and fresh is continually appearing. However that doesn’t mean that the 1.x branch has been forsaken, or forgotten. The 1.7 beta release has some pretty cool features that allow you to improve the performance of your application. What I want to focus on today is how to use a blacklist or whitelist with the 1.x build tools.

One of the biggest knocks against SproutCore 1.x is that it is a “big, monolithic framework”. You end up pulling in more than you’re ever going to use or need. This is a problem, particularly in a JavaScript context, because it increases the size of the file that needs to be sent down from your server, and then parsed by the browser. Particularly in a mobile context, this can be a serious performance drain.

Enter the SproutCore whitelist/blacklist. If there is a section of SproutCore 1.x that you’re not using inside of your application, you can use either a whitelist or a blacklist to tell the build tools not to include that code in the final packaged version of your application’s JavaScript. So for example, if my application is not using collection view, I could create a file called Blacklist inside of the root of my file directory, and put the following into it to exclude collection view:


{
"/sproutcore/desktop": "views/collection.js"
}

“/sproutcore/desktop” is the “target” for the build tools, which you can think of as basically the framework to target. Then, “views/collection.js” which is the “rule” for the build tools. If the list is a whitelist, then the rule would mean to include the file in the final build, whereas if the list is a blacklist, then the rule would exclude that file. So in this case, “/sproutcore/desktop”: “views/collection.js” tells the build tools to exclude the file “views/collection.js” from the desktop framework.

So if you have a 1.x app and you’re looking to improve the initial load time of your app, I would create a blacklist for your application, and go file by file seeing what you can exclude from the framework. Happy optimizing.

Dispatch From The Edge: Handlebars Debugging Helpers

written by Greg Moeck

Comments Off

Greetings all! It’s been a bit since our last Dispatch, and the edge waits for nobody, so quite a lot has been going on. This week I’m going to focus on a couple of helpers that have been added to aid in the debugging of view rendering with Handlebars templates.

Generally, when people start trying to debug a problem in their JavaScript, they go about it in one of two ways. Either they try and use console.log to log a value to the console, or they insert a debugger statement that essentially functions as a breakpoint that stops execution of the application at that point.

Both of these techniques have always worked fine inside of SproutCore, except inside of a Handlebars template. Since Handlebars does not allow you to execute arbitrary JavaScript code within your template, you were left trying to log or debug the view property that you were trying to display.

Enter two new Handlebars helpers: log and debugger. Now you can log a property on the template or add a debugger statement to pause execution directly into the template itself. What would this look like? Consider the following code:

1
2
3
4
5
  <div class="some-item">
    {{log name}}
    {{debugger}}
    {{name}}
  </div>

This would log the name property to the console, and then stop the execution, setting the current “this” property to the template. This means that you can do a this.get(‘name’), or any other property, on the template and it will print the value to the console window.

If you interested in how to do this sort of thing for yourself, the source file is very simple and you can read it for yourself here.

Hope this helps you in debugging your busted templates. Until next time this is Greg signing off.

Dispatches From The Edge: Handlebars Without Spans

written by Greg Moeck

Comments Off


As more people have been using templates to map the state of their views into the DOM, a couple of questions have continually come up. In this week’s Dispatch, I want to focus on how SC.TextField solves one of the common questions and offer some advice on building similar custom views.

Let’s first specify the common question: How would one go about implementing something like a textarea tag? Just about everyone tries to do it like this:

<textarea>{{content}}</textarea>

You would like it to render something like this:

<textarea>Some Content</textarea>

But instead, SproutCore outputs something that looks like the following:

<textarea><span>Some Content</span></textarea>

Why would SproutCore wrap your content inside of the span tag? Because the Handlebars template isn’t only responsible for the initial rendering, it’s also keeping that rendered content in sync with the state of your view. Because of this, it needs to be able to target an element inside of the DOM to replace when the state of your view changes. So SproutCore inserts that span tag into the rendered DOM so that it can later change the DOM when content changes.
Continue reading

Dispatch From The Edge: New Controls Built on Templates

written by Greg Moeck

18 Comments

The construction of the view layer has been greatly simplified by the new way of delegating the view’s rendering to templates. With templates, most things have gotten easier to do– particularly view rendering. However, there are a couple of benefits that the older ways of building views provide that became a bit more difficult within templates– namely, building controls. In this post, I’ll take you through the ways in which Templates have affected how we construct controls, and how to build yours as efficiently as possible.

Before templates, we had several drop-in objects that handled common controls. If I wanted to add a button to a view, all I had to do was something like this:

SC.View.extend({   
  button: SC.ButtonView.extend({     
   target: object,     
   action: 'something'   
  }) 
})

What was nice about this approach was that you didn’t have to worry about describing exactly how the button renders, or how it responds to things like mousedown or mouseup. This was convenient because generally all buttons have the same structure and code, and it let us work at a higher level of abstraction. If we were to do this inside of a new template structure, we would have to do something like the following:

views:
 
BaseView = SC.TemplateView.extend({   
        templateName: 'some_template' 
})
 
CheckAllView = SC.TemplateView.extend({   
    target: object,   
    action: 'something,   
    ...   
    mouseUp: function() {     
      ...
      this.get('target')[action]()
      ...
    }
    ...
 })
 
template:
<div class="something">
    ...   
    {{#view CheckAllView }}      
 
    {{/view}}   
    ...</div>

Continue reading

Dispatch From The Edge: Contributing To Sproutcore

written by Greg Moeck

4 Comments

The recent release of 1.5 has brought many new people to SproutCore, and as our community grows, more and more people are asking how they can help. This week, instead of focusing on whats new, I’m going to focus on how you can contribute to the bleeding edge of SproutCore. I’ll start with my top three suggestions.

1. Contribute to the SproutCore Guides

Back in the beginning of January, we recognized that the biggest challenge to new users trying to learn SproutCore was the limited quality and quantity of documentation. To solve this problem the SproutCore Guides project was born. To date, 15 guides have been completed and made available to the community, drastically improving the help that is available for people. But there’s still more work that can be done.

How can you start helping?

To be able to contribute to the project, the first thing you need to do is build the guides on your own system. In order to do that, do the following:

  1. Download and install the guides package
  2. Clone the guides source from git://github.com/sproutcore/sproutguides.git (git clone git://github.com/sproutcore/sproutguides.git within the directory you want to work).
  3. cd into the cloned directory (sproutguides), and run “guides build” to generate an the output directory, where you can build the files locally.

Once you’ve set up the directory, you can modify any of the files within the source directory.

Next, run “guides generate” to see them reflected in the output. The following video illustrates a typical workflow:

If you’re interested in writing a new guide for a section of SproutCore that hasn’t yet been covered, contact Yehuda at wycats@sproutcore.com with your idea.

2. Contribute to the Source Itself

There are two ways that you can contribute to improving the code of SproutCore itself.  Continue reading

Dispatches from the Edge: Template Views Part 2

written by Greg Moeck

2 Comments


In the last Dispatch we looked at how SproutCore incorporates the standard handlebars.js expressions and and helpers, and how bindings are automatically set for those expressions. This week, we’re going to take a look at some of the other ways that SproutCore extends handlebars.js to make interaction with the DOM even easier.

Class Bindings

A template needs to do more than tell the browser what content to display it also needs to tell the browser how to display that content. For example, in a to-dos application, we want our template to define what the to-do is, and if it has been completed, but we might also want to specify other aspects of the display. Maybe we want the text to grey out, or have a line through it once the to-do has been completed. How would we do this?

Well, with HTML we can modify the display using CSS. SproutCore has some helpers to make this easy. For example, If I wanted to have a class be added to an element only when a property is true I can use the classBinding helper. Let’s look at a concrete example.
Continue reading

Dispatches from the Edge: Part 1, Template Views

written by Greg Moeck

9 Comments

More and more developers are adopting SproutCore every day, and the need for great documentation and tutorials just keeps growing. The Core Team is also making rapid progress on the new parts of SproutCore—the so-called sexy Edge. We’ve got the fantastic new SproutCore Guides to tackle the mainstream parts of SproutCore, and now, I’m aiming to tackle the new and exciting Edge parts. 

Every other week I’ll be posting what I’ll call Dispatches from the Edge. Each Dispatch will highlight a feature from the most recent release of SproutCore, explain how to use it, and wax on about why it’s so darn cool. Dispatches will also be where the team posts announcements about upcoming SproutCore-related events. Online, offline, we’ve pretty much got it covered :)

I’d like for this to be as helpful and interesting as possible, so if there’s something you want to know about, do let me know. Comment, tweet, email—I’ll be listening!


There’s been a lot going on in the world of template views lately, making it an optimal first topic for the Dispatch. One new feature stands out as being particularly exciting… so I’ll start there :)

When you create a template for a view, that template is really specifying what the display should look like all the time. Since that’s the case, when one of the properties of the view changes, it would be nice if the view would automatically redraw that section of its display to accomodate the changes in the data. The new template view does just that.

Let’s look at an example:

Dispatches from the Edge Part 1a from SproutCore on Vimeo.


Continue reading