techwraith / ribcage-view Goto Github PK

Hi!

The raf module has introduced breaking changes in v1.0.0. The event emitter logic has been moved into raf-stream, while raf retains the actual polyfill logic.

Let me know if you need any help migrating.

What if we remade bindEvents to have 1) a nicer API, and 2) auto-call stopListening?

Here's my thought: we could copy the backbone events object syntax:

, events: {
  'click .mything': 'onMyThingClick'
}
, bbEvents: {
  'change:key model': 'onModelChangeKey'
}

• keys would be split on a space, just as the events hash does
• the first part of the key would be the event to listen to
• the second part of the key would be the object to listen to. this. would be assumed. If omitted, it will listen on the view itself
• the value would be the name of the function to call
• bindEvents would then become the method that parses this object. If over-ridden, (as we do now) things would behave as normal. Else, it just parses the bbEvents object. That makes this backward-compatible.

Adding lots of subviews is pretty slow, and could be optimized by using a documentFragment.

:)

Checkout the perf branch.

Right now, we call it on every render, which is slow.

In the case that a model doesn't have an id, falling back to the cid (which is guaranteed to be there) would prevent breakage.

Here's a requirebin: http://requirebin.com/?gist=7127537

It looks like rendering a parent view clobbers the events on all the subviews.

This means that on every render, all my subviews have to be reinitialized, which is pretty expensive.

I'm not sure if this is a problem with the way i've structured my application or an actual bug in ribcage-view. I feel like i should be able to render a parent view without wiping out all my subviews.

Currently, it's not possible to ensure that things we need to listen to are loaded before attempting to listen to them.

https://github.com/joeybaker/wheelhouse-view is a previous project that I worked on that has a lot of the same ideas of this project. Maybe steal some of them?

Ideas

• optimized subivew rendering with a documentFragment #7
• the parent property for subviews #24 ← rightly rejected by @techwraith b/c it's to tightly coupled. Just use events.
• have the context auto-set to the model.toJSON or collection.toJSON if it's present https://github.com/joeybaker/wheelhouse-view/blob/master/view.js#L21-L25
• maybe the idea of collectionChildren to automate creating "collection views"?
• the removeInner method which allows the view to be destroyed by keep it's element in the DOM. Useful when the view is attached the main app container.

#7 talks about using a document fragment to optimize sub-view rendering. An idea I've always had it to further optimize for a large number of subviews (> 50~ish?) and use requestAnimationFrame to batch up the rendering so that the DOM doesn't lock up.

Would love some tests if possible :)