marionettejs/backbone.marionette

(⊃｡•́‿•̀｡)⊃━☆ﾟ.*･｡ﾟ The Backbone Framework: http://marionettejs.com

Paul Falgout

@paulfalgout

In v5 it’s this: https://github.com/marionettejs/marionette/blob/53da4e7215e3ec721523407e384d142ef41a8e53/modules/common/view.js#L1

there’s a handful of things on v5 that are buggy in the alpha though.. not sure about where that’s going. But with Backbone gaining some momentum who knows?

dimtabu

@taburetkin

so, this object

{
  render() {},
  destroy() {},
  triggerMethod() {}
}

will be treaten as view, as i can see

Paul Falgout

@paulfalgout

yep. don’t think you really even need triggerMethod

dimtabu

@taburetkin

sure you need

renderView will throw without it

Paul Falgout

@paulfalgout

yeah it’d probably be odd to set supportsRenderLifecycle, but you could

dimtabu

@taburetkin

export function renderView(view) {
  if (view._isRendered) {
    return;
  }

  if (!view.supportsRenderLifecycle) {
    view.triggerMethod('before:render', view);
  }

  view.render();
  view._isRendered = true;

  if (!view.supportsRenderLifecycle) {
    view.triggerMethod('render', view);
  }
}

if a view HAS NO supportsRenderLifecycle there will be call to view.triggerMethod
so, i believe, for every not mn5 view.

so, my custom view should have triggerMethod() {} or supportsRenderLifecycle: true

Paul Falgout

@paulfalgout

Well so you’d set view.supportsRenderLifecycle if your view's render was triggering those events.. but I can’t think of anything offhand that’d explicitly break if you indicated that it did trigger them, but then it didn’t..

so I think nooping the triggerMethod or setting those two flags to true is effectively the same thing

well it’s definitely the same thing.. but I believe not actually triggering those events is ok.

dimtabu

@taburetkin

i think that if i am supplying some custom view its my bussines to trigger events or not.
i mean that if i need those events i have to implement render lifecycle in my view

Paul Falgout

@paulfalgout

yep so you’d just set those flags true. What that functionality is essentially for in particular is legacy stuff where someone is using a backbone plugin that makes some backbone.view but they want marionette style lifecycle when show in a region

dimtabu

@taburetkin

original backbone view by default will throw because of missing triggerMethod and supportsRenderLifecycle

dimtabu

@taburetkin

maybe its ok to check if a view has triggerMethod ?

   ....
  if (!view.supportsRenderLifecycle && view.triggerMethod) {
    view.triggerMethod('render', view);
  }

Paul Falgout

@paulfalgout

well so I don’t remember when but we added a mixin for supporting backbone views https://github.com/marionettejs/backbone.marionette/blob/master/docs/events.class.md#supporting-backbone-views

but all it does is add a triggerMethod function

dimtabu

@taburetkin

yeah, i saw it early

i just not really understand why to trigger something on a view without supportsRenderLifecycle while rendering.
1) if my custom view has render and there some code related to render event why i cant implement it in my render?
2) if i do not know about mn render life cycle and internaly have render hook for other purpose i definitely will get side effect after rendering my view in a mn region

Paul Falgout

@paulfalgout

Often times it’s some other libraries view, so the user isn’t implementing the render function. And if the view is handling those events you’d just set the flag

dimtabu

@taburetkin

i can imagine that. but can't imagine that other library viewlike object have supportsRenderLifecycle: true or triggerMethod :)

dimtabu

@taburetkin

Paul, what do you think about some marionetteConfig in Mn5?
what if there will be one:

export const marionetteConfig = {
  DomApi: DefaultDomApi,
  viewRenderer: DefaultViewRenderer,
  .... // other configurations
}

and in a view it could be:

 - Dom: DomApi,
+ getDomApi() {
      return marionetteConfig.DomApi
    }
   ...

and changing the domApi will be like

import { marionetteConfig } from 'backbone.marionette';
marionetteConfig.DomApi = MyDomApi;

Paul Falgout

@paulfalgout

I think that’s essentially the idea https://github.com/marionettejs/marionette/tree/master/config

And the issue is poorly written, but there’ll be a second option marionettejs/marionette#3

which is essentially making v5 like v4 or very close

dimtabu

@taburetkin

also, maybe someone can find it interesting
https://github.com/taburetkin/js-entitybuilder

dimtabu

@taburetkin

this lib was inspired by marionette technique of constructing Behavior instance
and personaly i borrowed that for constructing my views and other entities
please feel free to criticize or suggest changes.

Peter Dietrich

@xosofox

Hey, very "general" question... I'm runnin Marionette 3.5 in a webpack build, using "import"
Now, should I

import Marionette from 'backbone.marionette';

import Marionette from 'backbone.marionette/lib/backbone.marionette.esm';

import {View} from "backbone.marionette";

Or any other?
Any advantages of one or the other? Tree-Shaking maybe?

Paul Falgout

@paulfalgout

Hmm.. I don’t think you should do the 2nd one. And I don’t think tree-shaking works in v3.

dimtabu

@taburetkin

@paulfalgout Hi Paul
have a question about view.destroy
what actually it means?
it's a some kind of disposal pattern implementation or somehing else?

dimtabu

@taburetkin

also, can you explain the purpose of dom:refresh, dom:remove etc events?

Paul Falgout

@paulfalgout

@taburetkin destroy cleans up anything constucted within Marionette so that if a view's instance is no longer referenced the view can be cleaned up by the browser's garbage collector.

dom:refresh reflects when the contents of a view's el change in the DOM, and dom:remove reflects when the contents of a view’s el are about to change in the DOM.

These events are ideal to setup any external DOM listeners such as jQuery plugins that use DOM within the el of the view and not the view's el itself.

that’s assuming the jQuery plugin cares that the DOM is attached to the document, which many do.

dimtabu

@taburetkin

ok, thx.
as i can see, destroy is a disposal pattern implementation.
under the hood there is only .stopListening() in mn destroy cycle.
there are definitely own events exists after destroy, also jquery and dom elements too, and options object
is it not worth to clean everything, i suppose ?

this.stopListening();
this.off();
for(let prop in this) {
  delete this[prop]
}

Paul Falgout

@paulfalgout

anything using marionette’s event listeners are cleaned up. onBeforeDestroy is a provided hook for cleaning up anything add externally. There’s no need to delete own properties for garbage collection

marionettejs/backbone.marionette#1219

dimtabu

@taburetkin

you wrote stopListening will work because this.on is essentially this.listenTo(this and you know what? this is not almost true

@paulfalgout

dimtabu

@taburetkin

Paul Falgout

@paulfalgout

I’m not sure what point you’re making. Self references are garbage collected just fine. There’s absolutely no point in cleaning up this.listenTo(this

dimtabu

@taburetkin

i tried to say that this.listenTo(this is not equal this.on( :)) only that.
btw, not sure i am understand what the difference between _events and _listeners. I mean that i know what it means in terms of backbone
just cant get why stopListening but not off.
correct me if i am wrong - instance will be GC if there is no other reference to this instance, no mater how many other instances its pointing, right?
...
i think i got this while write this big message.
stopListenning exactly removes other instances links

Paul Falgout

@paulfalgout

yes that. stopListening removes other references.

there’s no reason to ever do this.listenTo(this as it is exactly like this.on except that it keeps a 2nd hash of objects it references.. which is particularly not useful when listening to self.

dimtabu

@taburetkin

i know, i just folowed your issue link and just found there ... nvm :))))

dimtabu

@taburetkin

HI all
i am going to try this approach:

// just for example
const model = new Model({ created: new Date(), bigNumber: 123456789 });

// some schema implementation
const modelSchema = {
  // ....
  display(property, model) { return; // some logic here }
}

const ModelView = View.extend({
  model: model, 
  template: _.template('<%= display.created %>: <%= display.bigNumber %>'),
  templateContext() {
    return {
      display: createDisplayModelProxy(this.model, modelSchema)
    }
  }
});

function createDisplayModelProxy (model, schema) {
  const handler = {
    get (target, name) {
      return schema.display(name, model);
    }
  };
  return new Proxy(model.attributes, handler);
}

has anyone ever done something like this? can you share any of your thoughts?

Where communities thrive

People

Repo info

Activity