szymonrw / ancient-oak Goto Github PK

Hey @brainshave, would like your thought regarding implementing the tail function atop ancient-oak. In vanilla JavaScript it would look like:

[1,2,3].slice(1)
// [2,3]

In ancient-oak:

Nope:

oak([1,2,3]).rm(0).dump()
// [ , 2, 3 ]

Cute, but there should be a more performant way:

oak([1,2,3]).reduce(function(acc, x, i){ return i === 0 ? acc : acc.push(x) }, oak([])).dump()
// [ 2, 3 ]

I constantly get
node_modules/ancient-oak/lib/balanced_storage/storage.js:48
var set = modifier({
^
RangeError: Maximum call stack size exceeded

when trying to use ancient-oak on something like this: http://hastebin.com/uxeneconom.dos

could you make this into an npm and bower packages for easy usage in projects (both front-end and back-end)?

I think we need an .eq(...) function that will accept any

• plain array,
• object,
• ancient-oak instance

and figure out if the values are the same.

Is it possible to generate a json patch operation when forking ... to sync with backends that support the patch operation?

I'll be happy to help with this.

Lets add support for http://github.com/component/component

Then people will be able to do:

component install brainshave/ancient-oak

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({})