Does implementing Shadow DOM in my projects will make them faster like virtual DOM that's used by React?
They are different things for different purposes, so comparing performance doesn't make sense.
Virtual DOM
Virtual DOM is about avoiding unnecessary changes to the DOM, which are expensive performance-wise, because changes to the DOM usually cause re-rendering of the page. Virtual DOM also allows to collect several changes to be applied at once, so not every single change causes a re-render, but instead re-rendering only happens once after a set of changes was applied to the DOM.
Shadow DOM
Shadow dom is mostly about encapsulation of the implementation. A single custom element can implement more-or-less complex logic combined with more-or-less complex DOM. An entire web application of arbitrary complexity can be added to a page by an import and <body><my-app></my-app> but also simpler reusable and composable components can be implemented as custom elements where the internal representation is hidden in the shadow DOM like <date-picker></date-picker>.
Style encapsulation
Shadow DOM is also about preventing styles being applied accidentally to elements the designer didn't intend to, for example because the CSS or components library you are using changed a selector that now applies to other elements that use the same CSS class names. Styles added to components are scoped to that component and bleeding out or in of styles is prevented.
Shadow DOM and performance
Even though shadow DOM is not about performance in the first place it also has performance implications. Because styles are scoped, the browser can make assumptions about some changes to affect only a limited area of the page (the shadow DOM of a custom element) which can limit re-rendering to the area of such a component, instead of re-rendering the entire page.
This is the reason the >>>, /deep/, and ::shadow CSS combinators, which allowed to apply styles across shadow DOM boundaries, were deprecated and are subject to be removed soon from Chrome (other browsers never had them AFAIK). The mere existence of these combinators prevents the kind of optimization mentioned in the previous paragraph.
Angular2 uses the advantages of both worlds.
It uses unidirectional data flow and runs change detection on the model only. If it detects changes it causes the DOM to be updated by updating bindings and make structural directives like *ngFor, *ngIf, ... update the DOM. Therefore the DOM is only updated when the model actually changed.
Angular2 uses shadow DOM (only with ViewEncapsulation.Native which is currently not the default) to utilize style encapsulation capabilities provided by the browser, or (current default) just emulate style encapsulation by rewriting styles added to components, as a workaround until native shadow DOM and CSS variables (for dynamic global style changes) become widely available.
No, Shadow DOM and Virtual DOM are unrelated, although somewhat similarly named:
Virtual DOM: React concept of keeping two copies of the DOM (the original, and the updated) for differential reasons. Before rendering, React diffs the two objects to determine if it should apply an update(s) to the actual DOM tree. This results in boosted performance, as we're only updating the portions of the view that require it, not the entire screen.
Shadow DOM: Part of the Web Components spec as proposed by W3C, which basically allows the encapsulation of smaller DOM elements and CSS styles into a single DOM element:
Example Shadow DOM Element
<my-video width="300" height="150" />
However, <my-video> actually encapsulates the following elements:
<div>
<input type="button" style="color: blue;">Play
<input type="button" style="color: red;">Pause
<source src="myVideo.mp4">
</div>
So by using Shadow DOM, we're able to hide the implementation details of our web element, and only pass along necessary information to the sub-elements (i.e. height, width), which, perhaps confusingly, strongly resembles the ReactJS idiom of passing props to components.
Information provided via:
http://www.funnyant.com/reactjs-what-is-it/
http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
Related
In Material-UI v4, you were able to use the Mui* class names on any elements and have the styles of those classes take effect, as long as the MUI components that use those classes are incorporated somewhere (thereby injecting the styles into the page CSS). For instance, you could add class names like className="MuiTypography-root MuiLink-root MuiLink-underlineHover MuiTypography-colorPrimary" to some HTML element to match all of the styles of a MUI <Link />, like in this codepen. In MUI v5, this has no effect, as can be seen in this identical codepen using MUI v5, despite the fact that the class names are still being used on the MUI <Link /> (just not to apply CSS).
Applying MUI component styles to non-MUI components is important for a few different use-cases, where you need to apply styles to APIs that do not support supplying React components directly. For instance:
When using react-router-dom's NavLink component with its activeClassName prop. In this case, the base component is styled a certain way, and you apply further classes (not props) to modify its styles when the NavLink is the "active" route. In MUI v4, you'd be able to use classes like activeClassName="Mui-selected" (for components that have a selected state), or MuiButton-outlinedPrimary to change a button variant via only classes.
When using external APIs that deal with raw HTML elements, like rich-text editors (Tiptap, Draft.js, etc). It's useful to be able to pass MUI class names directly here so that you can style the rich-text elements to match MUI styles (like the link element in the above codepens).
The only way I can determine how to do this in MUI v5 is to use the deprecated makeStyles and create classes that duplicate all of the MUI styles manually. e.g. duplicate all of the CSS of Mui-Link-root within my own makeStyles call, then use the useStyles() generated class to apply the CSS. This would lead to significant duplication of MUI code and isn't a sustainable or even straightforward option. It would be simple in situations where you can use just the theme, like myBody1: {...theme.typography.body1}, but it's unclear how to do this for other components without copy-pasting from the generated CSS or MUI source.
This is related to this other question Apply MUI styles to non-MUI markup elements, but slightly different in scope, as I would like to reuse MUI's styles via class names I can apply to other elements (whereas that question would like to do so without using class names at all).
I have a VCL form which (in addition to all the other controls) has 20 edit boxes on it that are hidden. They are essentially there as boolean variables so I can utilise their OnChange event to trigger other things.
Even though these are enabled but not visible, will they have a noticeable impact on the form load time, particularly as I am using VCL themes as well?
This article would suggest they are not created until referenced or made visible, but since I reference them during form load then I assume they will be created then. I suppose the bulk of the 'create time' is in the painting, but I figure they are not being painted if hidden so we are saving time there, therefore is the time I am left with likely to be noticeable?
In most of the Activities and Places examples I've seen, people use a SimplePanel as the display for an ActivityManager.
I was wondering if there's a benefit to using a DeckPanel/DeckLayoutPanel instead of SimplePanel. It's fairly trivial to create a wrapper around a Deck panel that implements AcceptsOnWidget.
I haven't seen this topic discussed anywhere. Prior to MVP+Activities being commonly used in GWT, people generally used Tab panels (which internally uses deck type panels) and Deck panels to control switching between panels within a given view.
The difference between the two is SimplePanel.setWidget(..) will remove the previous child from the DOM and append the new widget whereas a deck type panel will use CSS to control visibility of the current panel (i.e. "display: none" to hide inactive panels).
If using a deck panel, it generally means you will have much more Elements in the DOM. I would imagine this uses more memory and makes the application "sluggish", even if those nodes are not visible ("display: none"). Is this true?
If this is true, why did Google use a deck panel style impl for TabPanel/TabLayoutPanel instead of internally using a SimplePanel?
Is one approach more favorable over the other?
Performance wise there is no difference. It all depends how you use it. In the DeckLayoutPanel all children are kept in memory. But if you would implement the same thing with a SimplePanel you need to keep a pointer to those same children yourself, so the memory footprint would be about the same. Unless with a SimplePanel you create and render a child each time it's shown and throw it away when hidden, which would possible be memory efficient (if the garbage collector does it's work), but it would be a hit on usability since rendering is expensive.
Second if you use a DeckLayoutPanel all it's children are created at once, while only one is shown. For performance this might not be optimal. So for this reason you could add a LazyPanel between the child and the DeckLayoutPanel, so it's only created when shown. But that might take some extra coding to make it work (because it's lazy you need to lazy initialze it which can cause some difficulties) However, still for the comparison between DeckLayoutPanel and SimplePanel it's only a matter of when you would create the children for the SimplePanel (all up front == same issue as with DeckLayoutPanel) and not something specific to the difference between DeckLayoutPanel and SimplePanel.
In general if you have a defined ordered set of children use a DeckLayoutPanel (like with a TabPanel) and if you have a undefined set SimplePanel is the better choice (like in MVP to show the current view).
DeckLayoutPanel internally holds collection of all your views (actually views that you've registered or displayed) in order to be able to determine sliding animation direction (depending if you go back or forward). Apart from this, I didn't notice that application become sluggish when switched from SimplePanel do DeckLayoutPanel. It's especially safe, when all your views are singletons. But please aware that in such case, when switching between the same view instance (for example main categories list -> subcategories list), DeckLayoutPanel may have some problems rendering sliding animation.
In my opinion there is no favorable solution - if you don't need "sliding" panels, I would not use DeckLayoutPanel (since all additional components increases complexity).
I'm fighting to understand the weird behavior of GWT Layout Panels. I'm wondering how GWT translate Layout logic into javascript and html. sometimes we don't get the expected Layout . something under the cover is done by GWT compiler.
the GWT documentation is not clear enough on how Layout is performed under the cover.
is there some good books or tutorials that explains well the GWT Layout issues?
thanks.
I don't know about good books or tutorials but here's a little information that may be helpful.
First, as you may know there's a big difference between the FooPanels and the FooLayoutPanels. These are two different sets of panels that are based on different layout mechanisms. The Layout Panels are the new stuff that seems to be suited better for layouts that have hard-coded sizes, Google Wave style. The older FooPanels (VerticalPanel, etc.) are based on HTML tables mostly.
FlowPanel - this is simply something that outputs your widgets as successive HTML elements in a single DIV. As documented: "A panel that formats its child widgets using the default HTML layout behavior".
DockLayoutPanel - Looking at the code shows that it hard-codes the sizes of the different regions according to what you specify in the children (north, east, etc.)
Finally - my experience has led me to abandon all usage of the Layout Panel system and rely only on HTML and CSS wherever I can. This means using HTMLPanel + UiBinder mostly and sometimes FlowPanel, rarely also some of the other panels.
Trying to understand and battle the Layout Panel system to do things that are not the "default case" was a waste of time. I'm not saying it's the best thing to do, but I just couldn't get the kind of control I wanted without this - especially with regard to elements that should automatically expand vertically. If you haven't already, take note of this from the GWT documentation about Layout Panels:
The panels described above are best used for defining your application's outer structure — that is, the parts that are the least "document-like". You should continue to use basic widgets and HTML structure for those parts for which the HTML/CSS layout algorithm works well. In particular, consider using UiBinder templates to directly use HTML wherever that makes sense.
I'm really struggling with a choice between the GWT Tree widget, which has been a part of GWT for ages; or the new CellTree, which is introduced by GWT 2.1.
The tree I want to present to the user is not particularly large, but I am very concerned about responsiveness.
The data at the nodes of the tree will be editable. By clicking on a node, the user will put the node into edit mode. Editing the more simple nodes will require only a single TextBox or TextArea; but others will involve several widgets, over which I want styling control via CSS.
I'm attracted to the CellTree approach because it seems to offer great flexibility and speed; however, the sample code for CellTree editing deals with only very simple data types: string, date, integer, etc. I don't know if CellTree is appropriate when you've got more complex node-editing needs.
What do you think? Is CellTree the best approach? Does CellTree replace Tree in general? What heuristics can I apply in choosing between them?
I'm using a CellTable with several custom input Cells, including one comprised of many widgets. It works great!
It took me a couple of hours to understand how to implement a custom Cell that could do complex operations - since a single instance of the Cell will flit around the CellTree, pretending to be many instances, you need to understand how it's getting its data and when it is refreshed and rendered. I learned a lot from the source of the DatePickerCell.
I can't speak for CellTree, but the CellTable is very flexible, was easy to program, and saves me hundreds of Widget instances.
Using CellTree is problematic. Because it hasn't good access to view implementation stored in CellTree. It cause problem (ex. for me :D) in making custom handlers for opening nodes with children by clicking on whole parent cell. Of course you can make custom cells by AbstractCell, where you must write own renderer.
I think this widget must be enchanced and more objects must be more visible for users.
Customizing CSS is simple. All what you have to do is extende CellTree.resource and insert own css based on celltree.css class names.