Tips for upgrading to 1.10?

[Dave Porter]

Hi all,

Everyone that's upgraded a project to 1.10, please read!

1.10 is a stupendous update, but there are a couple of changes that prohibit previously allowed (wrong) behavior. This stuff shouldn't be happening, but it definitely is, and we need to communicate clearly about it. (Proactive would be best, as not everyone is going to hit up the mailing list before they give up!)

The two big challenges for upgraders that I see are the invokeOnce/invokeEtc warnings and the new list view example view reuse behavior. Chime in if you've seen any others.

Regarding the invokeOnce warnings, users are going to see a whole lot of warnings with the occasional break. This is going to be true even if the user never calls invokeOnce in their own code, so I'd like to put together a list of potential causes of this so folks have any idea at all where to start. For example:

- Creating views when you should be extending or designing them (i.e. in your initial view layer definition, which happens before App.main() and therefore before there are runloops).

- Failing to start a run loop when handling browser events (rather than properly wrapped SC events) like field focus or WebSocket events.

If we can get a solid list together, we'll help a lot of folks transition faster. What else have you guys noticed?

Similarly a few folks have found that their list views are no longer updating when scrolling. Since many more views will be reused now, a lot of formerly silent bugs with missing displayProperties or broken update methods are going to surface. The information that folks need to fix it is all in the View guide, but maybe a dedicated guide (or blog post) for getting the most out of the new list view architecture might be in order? Anyone have any time to put such a thing together?

Thanks all, this is an important update for us and it would be great if it went as smooth as possible!

Cheers,

Dave

[Tyler Keating]

Re: collection view updating

There is a blog post on this, everyone should read it: http://blog.sproutcore.com/dispatches-from-the-edge-super-fast-collections/

I can write a blog post specifically on render/update again, since it's one of the most misunderstood areas. This won't happen too quickly though..

--

Tyler Keating

ty...@sproutcore.com

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dave Porter]

Thanks Tyler. Everyone should read that blog post, but I'm hoping we can provide something much more recipe-like. I can also put something together but also not right away.

Anyone re: invokeOnce triggers?

[Maurits Lamers]

I was a bit confused about the line "creating views when you should be extending or designing them".

This kind of line suggests that there is a best practice which is different than what I have been doing for quite a few years. 

A few of my apps are series of panes (like questionnaires). Until now I have just created them and then used append and remove in the state chart.

This allows me to do simply "MyApp.myPane.append()".

While porting a few apps to master, I have seen quite a few invokeOnce warnings, which went away by extending instead of creating and designing them as property of MyApp.mainPage. This last step is necessary to have the view instantiated, otherwise .append() will cause trouble.

In this approach I have to do MyApp.mainPage.get('myPane').append() instead of MyApp.myPane.append(). 

While this approach might solve some problems, I feel that it makes this also more difficult. Instead of two references I have three, the append invocation gets longer.

Additionally, if all panes in a complex app should be defined on the mainPage, it is much easier to lose the overview.

Am I wrong on this, or what would be the preferred approach?

cheers

Maurits

[Dave Porter]

Using SC.Page to manage instantiation of your panes (and their views), while essentially a convenience, is the canonical approach. You should not be creating views ahead of MyApp.main(), you should instead be defining your panes within pages and getting them from there. An extra reference in your one line of pane initialization code is in my opinion worth the convenience. It also speeds up launch of your app by not instantiating (heavy) panes until they're needed onscreen.

That having been said, while you shouldn't create views ahead of main(), it's standard operating procedure to create (say) controllers ahead of time, so why is the line drawn there? In "classic" OO, you don't create anything ahead of main(), so it's sort of arbitrary that only views get this classical treatment in SC. Tyler, you mentioned a while ago that you might be able to prevent the calling of invokeOnce during view creation, since the layout stuff that's calling it isn't necessary during that part of its lifetime anyway. That would solve this issue, and would save us a ton of support effort (and our less-publicly-engaged developers a lot of heartburn). Thoughts?

I guess our options are change SC.View to prevent invokeOnce when not attached, or take the opportunity to double down (AND COMMUNICATE) on the best practice of delayed pane instantiation via SC.Page.

[Dave Porter]

I guess I wouldn't mind if the warning went away, but I think we should definitely double down on the SC.Page best practice, since that results in faster-loading apps in the common case.