no clear information on what happens to jquery/bootstrap/dom manipulation in Glimmer

[mgenev]

This is really crucial for everyone with a real life prod app, yet though I've asked many times, I haven't heard any clear statement on whether we have to rewrite all the bits which now rely on directly touching the dom - every jquery plugin, bootstrap's javascript widgets etc. How about Dom events?

Please release this information so people know what decisions to make.

[stefanpenner]

Please release this information so people know what decisions to make.

This isn't documented, because nothing should have changed.

Maybe we are talking about two different things, could you enumerate specific concerns? I would gladly respond to each of them.

Note: discourse may also be a better venue, but use your description.

[mgenev]

2 specific concerns:

1) Can I manipulate the real DOM? Bootstrap and many other jQuery plugins use direct dom manipulation. Can we keep using them after the introduction of virtual dom?

If this is analogous to React, here's an example of what people say about doing this in React:

Broadly speaking, you shouldn't manipulate by hand the DOM that React has created. It's 100% kosher to create an empty

in React and populate it by hand; it's even okay to modify the properties of a React-rendered element as long as you don't later try to change its properties in React (causing React to perform DOM updates), but if you move an element, React may look for it and get confused when it can't find it.

http://stackoverflow.com/questions/23530716/react-how-much-can-i-manipulate-the-dom-react-has-rendered

To me this means, no we can't/shouldn't do DOM manipulation. I've never seen a statement about this.

2) DOM events

If I'm firing DOM events from Ember, can I still do that? Is the virtual dom going to get in the way?

Many people are going to wonder the same thing.

[rwjblue]

This isn't documented, because nothing should have changed.

Agreed. If you are used to manipulating the DOM or triggering/handling events via a jQuery plugin, bootstrap JS, or just via native JS methods in your components, that should absolutely still work just as it did in prior versions.

If you have a specific example, please share it. In general Ember 1.x and 2.x should not differ in this capability.

[rwjblue]

1) Can I manipulate the real DOM?

Yes, just as in prior Ember versions you can manipulate the DOM in your components (or view for 1.x) didInsertElement hook.

2) DOM events

If I'm firing DOM events from Ember, can I still do that?

Yes.

Is the virtual dom going to get in the way?

There is no virtual DOM. :smile_cat:

[mgenev]

If you are used to manipulating the DOM or triggering/handling events via a jQuery plugin, bootstrap JS, or just via native JS methods in your components, that should absolutely still work just as it did in prior versions.

That's great to know, thank you. If I run into problems with real examples after introducing Glimmer, I'll share.

[stefanpenner]

Can we keep using them after the introduction of virtual dom?

Yup, if it was reasonable, and worked before, it should continue to work.

But let me share some additional information that may help fill in missing pieces.

For some reason, many incorrectly refer to Glimmer as a "VirtualDOM" implementation. I believe your confusion arises from this somewhat popular but incorrect description.

The concept both Glimmer and react share, is not VirtualDOM, rather diff'ing to detect what work needs to be down to keep the DOM presentation in-sync.

Both glimmer and react implementing Diff'ing, but it turns out they are diff'ing two different things.

Glimmer diffs data that powers the templates, so given the following template:

<div>
 <h1>{{title}}</h1>
 <p> some static text </p>
</div>

In Glimmer

If the template is re-rendered, it will diff the input data the template uses, which in this case is only title. It compares the data (title) with the last known data. If the data didn't change, nothing happens. If it did change, glimmer performs the lowest cost transform possible. In this case, something like h1.textContent = title.

In React

For a similar component, the entire component (or component tree) would be re-rendered which produces a new tree of virtual DOM nodes. This tree of virtualDOM Nodes is diff'ed against the last tree of virtualDOM Nodes, changes are detected, and react then decides what operations need to be applied to the real DOM to bring it back into sync.

TL;DR React diffs VirtualDOM nodes, Glimmer diffs the data.

---

Ultimately though, Ember 1.x, 2.x and react provide the correct life-cycle hooks (didInsertElement, 'didRender`) that inform you when you can manipulate/augment/decorate the DOM. It is in-fact true, that if you start adding/removing nodes managed by either framework, strange things start to happen.

For example, given the following template:

<ul>
  {{#each books as |book|}}
    <li>{{book.name}}</h1>
  {{/each}}
</ul>

If using jQuery, you begin to add or remove li in the ul, you, ember and react all wont (now or in the past) get along very well.

---

In summary, reasonable jQuery/raw DOM manipulation that already works, will continue to work.

[mgenev]

@stefanpenner thanks, that's the best explanation I've heard so far

[stefanpenner]

@mgenev I believe @tomdale has some more detailed technical posts planned.