Ember usage example

[kristianmandrup]

I just watched your EmberLondon presentation and was very intrigued. Reminds me a bit of the ReactJS concept to boost performance. Much faster to do reference equality checks than deep value checks.

However not sure if it would screw up the Ember observer model, changing the pointers. I guess this is why React functions without observers and data binding?

Would something like this work? or should I inject this at the routing level?

http://emberjs.com/guides/configuring-ember/disabling-prototype-extensions/

Native arrays will no longer implement the functionality needed to observe them. If you disable prototype extension and attempt to use native arrays with things like a template's {{#each}} helper, Ember.js will have no way to detect changes to the array and the template will not update as the underlying array changes.

Additionally, if you try to set the model of an Ember.ArrayController to a plain native array, it will raise an exception since it no longer implements the Ember.Array interface.

You can manually coerce a native array into an array that implements the required interfaces using the convenience method Ember.A

http://madhatted.com/2013/5/17/observing-enumerables-and-arrays-with-ember-js

Would be nice at least to leverage the efficient versioning capabilities, such as rollback (undo). But look like it takes a bit more tweaking to make Oak play nice with Ember datatypes such as Ember.Array.

Looks like an ImmutableArray using Oak would have to proxy or mixin Ember.Array API as defined in ember-runtime/lib/mixins/array.js

length, objectAt, objectsAt, nextObject, "[]", firstObject, lastObject, contains, slice, indexOf, lastIndexOf,
addArrayObserver, removeArrayObserver, hasArrayObservers, arrayContentWillChange, arrayContentDidChange, '@each'

I wonder if that would be enough, at least for Array!?

For an Object, it must at least proxy or mixin Observable in ember-runtime/lib/mixins/observable.js.

var Oak = I; // alias

App.ImmutableDataWrapper = Ember.Mixin.create({
  immutable: function(data) {
    return Oak(data);
  }
})

App.ImmutableObjectController = Ember.ObjectController.extend(App.ImmutableDataWrapper, {
  various key functions that normally return mutable object: {
    // wrap as immutable array :)
    return this.immutable(this._super());
  }

App.ImmutableArrayController = Ember.ArrayController.extend(App.ImmutableDataWrapper, {
    various key functions that normally return a mutable array: {
    // wrap as immutable object :)
    return this.immutable(this._super());
  }
}

App.PostsController = App.ImmutableArrayController.extend({})

[szymonrw]

Hi @kristianmandrup, apologies for coming back to this after long time. I wasn't getting any notifications from GH, my bad for not configuring it properly.

Although the talk was given at EmberLondon I have little knowledge of Ember internals (if you wonder what I was doing there: well, it's a very nice and open group for new ideas :smiley: ). There was a follow-up talk by @jgwhite that dived into Ember integration:

• video here: http://vimeo.com/89089876
• example project: https://github.com/jgwhite/ember-ancient-oak

Hope this helps.

[jgwhite]

@kristianmandrup I’m extremely interested in using Ancient Oak as the backing store for Redux because it promises such highly optimised performance for deep-tree patches.

Here’s a sketch of how you might use it with Ember: https://ember-twiddle.com/aa0efa238baa1122d541?fileTreeShown=false&openFiles=services.store.js

[kristianmandrup]

Thanks guys. I've since then switched to React. So I'd be interested in using it as an alternative for Immutable.js ;)

[szymonrw]

I used it recently with React and one thing I found in need to add was nmap method that returns a native JS array. This is useful when we want to return React component for each element. nmap is now available in the newest version.

I'm also working on a new version, much faster and more extendible, on the ramblings branch.

[kristianmandrup]

Awesome! Thanks @brainshave :) I wasn't sure whether this lib was still being actively developed and improved. Most such libs tend to die out. I'm glad you are keeping up the spirit and making it suitable for modern development patterns!