Separate Mn DOM interaction into a mixin for DOM plugin ease.

[rafde]

Separate Mn DOM interaction into a mixin for DOM plugin ease.

If you want to add a VDOM system or don't want to use jQuery, there isn't an easy way to override DOM interacting functions.

Expected behavior

Provide an easy way to find functions that do DOM interaction in order to override them.

Place all DOM interacting functions into a mixin that can be used to reference for overriding for plugin needs.
example

backbone.marionette/src/region.js

Lines 178 to 184 in 8604cd1

	const parent = view.el.parentNode;
	if (!parent) {
	return;
	}
	parent.replaceChild(this.el, view.el);

backbone.marionette/src/region.js

Line 200 in 8604cd1

this.el.appendChild(view.el);

...

const parent = view.el.parentNode;
if (!parent) {
  return;
}
parent.replaceChild(this.el, view.el);

...

this.el.appendChild(view.el);

would be replaced by a function from a mixin that looks like

// from mixin
replaceChild(newEl, oldEl){
  const parent = oldEl.parentNode;

  if (!parent) {
    return;
  }

  parent.replaceChild(newEl, oldEl);
},

appendChild(el, childEl) {
  el.appendChild(childEl);
}

...
// region file

// https://github.com/marionettejs/backbone.marionette/blob/8604cd11b7ca25bcc870184886590b076f80ac8d/src/region.js#L178-L184

this.replaceChild(this.el, view.el);

...
// https://github.com/marionettejs/backbone.marionette/blob/8604cd11b7ca25bcc870184886590b076f80ac8d/src/region.js#L200

this.appendChild(this.el, view.el);

Now you can override appendChild and replaceChild for VDOM usage.

this idea came from #3082 (comment)

In the very least it'd probably be good to abstract this.$el.replaceWith to a private function such that one function could be overridden.

Environment

1. Marionette version: 3.x
2. Backbone version: 1.3.3

[paulfalgout]

Yep I think it's be amazing to have a plugin API.. totally spitballing here.. but something like:

import vanillaJsPlugin from 'marionette-vanillajs';

// sets the default
Mn.setDomPlugin(vanillaJsPlugin);

/// Then later
/// There's one particular view I want another DOM plugin for
const MyView = Mn.View.extend({ ... });

// Where the jQueryPlugin ships attached to Mn as the default
// Default until it isn't the default in Backbone.
MyView.setDomPlugin(Mn.jQueryPlugin);

[rafde]

I was thinking more in the lines of

import myDomMixin from 'myDomMixin';

const MyBaseView = Mn.View.extend(myDomMixin);
// or const MyBaseView = Mn.View.extend(_.defaults({/*stuff for my view*/}, myDomMixin));

It's more explicit opt-in

Although I imagine

MyView.setDomPlugin(Mn.jQueryPlugin);

would internally look like

setDomPlugin(plugin) {
  _.extend(this.prototype, plugin);
}

It's almost looking like _.mixin

[paulfalgout]

It would be a very specific mixin. There was a similar conversation involving replacing the renderer in particular (which is still an idea I'm for)

And that's where using a static function for configuration came up for me.
#2911 (comment)

What I like about it.. is you can change all Marionette.Views without extending separate from CollectionView or you can change your own extended view.. or a just the global.. but you don't really have to understand what is going on. A very new user could import Marionette and the VDOM plugin without having to understand where to apply it to a prototype.

[rafde]

Based on the comment link, I can see it working there since its one change.
But I can't figure how it would work for implicitly replacing several APIs. They user would have to know what key-value object to pass to replace the APIs

MyView.setDomPlugin({
  replaceChild() { /* no replacing */}, 
  appendChild() { /* no appending */}
});

But I am guessing the responsibility is left up to the hypothetical VDOM plugin author to do the work while the Mn user would just import and set or just import if the author has an implicit apply.

So... 👍 to get DOM mixin for now?

[paulfalgout]

A yes for sure. 👍 abstracting everything for a mixin is great now.

But yeah I think the API I'm suggesting would be more for external plugins that handle the entire API. Like we'd provide an empty template for making DOM plugins.

I don't necessarily know why users couldn't just extend a few functions one-off for a particular view. But there'll be caveats to changing some functions.. and hopefully plugins can handle or at least better document how things change if you use a different Dom plugin.

[ahumphreys87]

this would be so useful for my native plugin I am working on!!

[rafde]

yeah, I thought about that also. But I can't fix your non-$ ui issue.

[rafde]

next...rafde:DOM-mixin start

I might have to override
remove
https://github.com/jashkenas/backbone/blob/96e94b3b6cc26aae190aa0a136037d729e3afa21/backbone.js#L1357

_setAttributes
https://github.com/jashkenas/backbone/blob/96e94b3b6cc26aae190aa0a136037d729e3afa21/backbone.js#L1463

maybe _ensureElement https://github.com/jashkenas/backbone/blob/96e94b3b6cc26aae190aa0a136037d729e3afa21/backbone.js#L1449

trying to draw a line.

[ahumphreys87]

I don't think anyone can fix that issue :( I think it will just need
documented. It's mor remembering that jquery isn't there to help anymore

On Wednesday, August 31, 2016, Rafael De Leon notifications@github.com
wrote:

next...rafde:DOM-mixin
next...rafde:DOM-mixin
start

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3145 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACZOuJRitS0oqAJJJze6wjNnyMg9vX5Mks5qlPpCgaJpZM4JvFxg
.

[rafde]

made some more updates in the PR. I think I am done relative to Marionette's explicit usage of $.