Best practice for optimizing/limiting observables/callbacks about knockback HOT 4 CLOSED

These look like useful helpers. Let me give some thought to the syntax...

I went with a nesting syntax for ko.DefaultObservable(obs, default_value) and put keys/requires/internals in the options or as nested options for more advanced defaults/localization. Do you think a syntax using options for static attributes is possible/desired? Similar to:

    class ContactViewModel
      constructor: (model) ->
        super(model, {keys: {
          name:     {key: 'name'}
          number:   'number'
          date:     {key:'date', localizer: kb.LongDateLocalizer}
          name2:    {key: 'name'}
        }}, @)

Please let me know what you think is a good syntax...

Cheers!

from knockback.

@pauljoey: one more thing. I think the cleanup code time is caused by kb.release being a bit too rigorous. There's an open bug requesting for a lighter version of kb.release (#48) which I'd like to revisit soon.

from knockback.

Just as well that it does take a while to deconstruct, it's a good indicator that I should be optimizing my knockback usage :)

The above-mentioned code structure is working great. I definitely think there's an appropriate utility to including such a feature into the Knockback core, which could be accessed via options. I think you could use the same syntax as your keys option.. call it staticKeys. It would require keys to also be specified in order to work.

I'd like to contribute when I get some time.. but I'm not optimistic about that being any time soon. Doh.

from knockback.

I've added statics and static_defaults to be natively supported. Here is the signature from the tests:

    view_model = new kb.ViewModel(
      new kb.Model({id: 1, name: 'Initial', date: new Date()}),
      {statics: ['name', 'author', 'description', 'tags'], static_defaults: {author: '(none)', description: null}}
    )

from knockback.