Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 08 11:16
    taburetkin opened #3701
  • Feb 13 12:50

    dependabot[bot] on npm_and_yarn

    (compare)

  • Feb 13 12:50

    dependabot[bot] on npm_and_yarn

    (compare)

  • Feb 13 12:50

    dependabot[bot] on npm_and_yarn

    (compare)

  • Feb 13 12:50
    dependabot[bot] commented #3700
  • Feb 13 12:50
    dependabot[bot] commented #3698
  • Feb 13 12:50
    dependabot[bot] commented #3699
  • Feb 13 12:50
    paulfalgout closed #3700
  • Feb 13 12:50
    paulfalgout closed #3699
  • Feb 13 12:50
    paulfalgout closed #3698
  • Feb 12 09:03

    dependabot[bot] on npm_and_yarn

    (compare)

  • Feb 12 09:03
    dependabot[bot] closed #3697
  • Feb 12 09:03
    dependabot[bot] commented #3697
  • Feb 12 09:03
    dependabot[bot] labeled #3700
  • Feb 12 09:03

    dependabot[bot] on npm_and_yarn

    Bump follow-redirects from 1.7.… (compare)

  • Feb 12 09:03
    dependabot[bot] opened #3700
  • Feb 11 20:01

    dependabot[bot] on npm_and_yarn

    Bump ajv from 6.10.0 to 6.12.6 … (compare)

  • Feb 11 20:01
    dependabot[bot] labeled #3699
  • Feb 11 20:01
    dependabot[bot] opened #3699
  • Feb 11 01:02

    dependabot[bot] on npm_and_yarn

    Bump pathval from 1.1.0 to 1.1.… (compare)

dimtabu
@taburetkin
ah.... there is no internal check?
so i literally can pass some strange object with correct methods and thats will be fine?
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
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';

or

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

or

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
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
image.png
dimtabu
@taburetkin
image.png
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 :))))