global object to broadcast to Behavior?

[Rolf-nl]

This is like a follow up on some older post: https://groups.google.com/forum/#!topic/clientside/G9G1pmup5dU

I'm now using storage more throughout a site. Storage is a wrapper/helper class for localStorage for storing in a namespace and first-in-first-out stuff.

I pass it to Behavior and Delegator using passMethod(s) (getStorage: Function.from(storage)). This worked fine for storing stuff etc.

Right now I have to update multiple tabs or windows open with the same site/page from what is inside the localStorage whenever some keys are changed.

For this I use the storage event that is fired from localStorage (exposed through my Storage class as a change event).

When doing some dirty tests I was doing it like this:

Behavior.addGlobalFilter('Foo', function(element, api){

    var foo = new Foo(element, {});

    var storage = api.getStorage();

    if (storage){ //false if there's no localStorage

        var updateFooFromStorage(event){

            .... //compare event.event.key, do something with a newValue, or not... etc.

        }

        storage.addEvent('change', updateFooFromStorage);

        api.onCleanup(function(){ storage.removeEvent('change', updateFooFromStorage);

    }

    return foo;

});

Does this make sense or should I do things differently? It feels a bit strange because I'm adding multiple 'change' event listeners, the compare the changed key with a element-specific-storage-key declared on the element (to which the behavior filter is applied).

Or is it just me using Behavior for stuff I shouldn't ;)

[Aaron Newton]

I think what I'd do is add events to the behavior instance which is intended to be an arbiter for such things. I.e. your filters subscribe to the behavior's events (api.addEvent('storageChange'...)) and then your storage class fires those events. Your implementation isn't bad, but I prefer to use events that pass arguments about state rather than passing instances around if I can. I don't always do that, but I try to. Here, your code breaks if storage isn't returned by api.getStorage(), where as you could write filters that can survive without it (in theory) if you instead subscribe to an event on the behavior instance...

I've so far not found any situation where Behavior doesn't work for me (except data-driven components like charts and live data grids which need to be driven by JSON, but even those I instantiate with Behavior). But there are times where I don't use it; it can be too cumbersome a tool for some things. While I can totally turn a DOMReady statement into a behavior, sometimes it's just overkill. There I'm trading convenience for reusability. Sometimes it's worth the trade.

--
You received this message because you are subscribed to the Google Groups "Clientcide" group.
To view this discussion on the web visit https://groups.google.com/d/msg/clientside/-/6GwuKMC4BzYJ.
To post to this group, send email to clien...@googlegroups.com.
To unsubscribe from this group, send email to clientside+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clientside?hl=en.

[Rolf-nl]

So what you're suggesting is the following?

var b = new Behavior();

b.passMethods({ 

//getStorage: Function.from(storage),

//...,

getBehavior: function(){ return b }

});

b.apply(document.body);

var storage = new SmartStorage({

onChange: function(){

b.fireEvent('storageChange', arguments);

}

});

If this is the case.... well I didn't know (or was not sure) if this was "accepted/allowed".. I am using api.addEvent and api.fireEvent inside of filters already, but not in the domready.

[Aaron Newton]

That's close to what I'd do. I'd probably change what's below and do:

var b = new Behavior().apply(document.body);

var storage = new SmartStorage({

  onChange: function(){

    b.fireEvent('storageChange', storage);

  }

});

//in your filter

api.addEvent('storageChange', function(storage){

  storage.foo();

});

To view this discussion on the web visit https://groups.google.com/d/msg/clientside/-/aInAIRKpp9UJ.

[Rolf-nl]

I ended up doing that too (though passing storage as well as the data coming from localStorage to make sure I always have the correct stuff). Also firing back to behavior a storageSet event to update stuff (which the storage instance picks up for further processing).

Thanks, I wanted to get rid of the big code block and this is much better especially when you have a dozen filters you might want to use it in.