I have an application that was coded with JSPs and now we are in the process to migrate to the pages to Facelets.
One of our PhaseListeners is manipulating the component tree, because it needs to find out some components in the tree and extract some of its values. But with Facelets, UIViewRoot does not return any children.
How can I get the same type of functionality with Facelets?
Thanks in advance,
Paulo
Retrieving UIViewRoot with this line should work:
FacesContext.getCurrentInstance().getViewRoot
My guess is that you are trying to manipulate the component tree in the first phase of JSF lifecycle. (link)
The first phase consists of retrieving the view, that is, the component tree, for the requested page. Therefore you can just explore the component tree after this phase has completed.
Use
phaseEvent.getPhaseId()
to see which phase you are working in.
Related
As far as I've read parents should store childrens data which would solve my problem simply because I could iterate through the tree, but I'm not able to come up with a solution that manages to do that in react.
To clarify:
My goal is to convert my JSX-Layout to a JSON-Object so that I can send it to my backend for further processing.
Currently each of the nodes handle the adding of a new child in themself. All nodes only know their immediate children.
The problem now is that I don't know how I could read the entire tree data structure.
For example: In Java I could simply add a child to a node by just accessing the node's reference and adding the new node to the list of childrens. Since I use functional components in React I'm not able to do that and probably need to pass down a event from the parent nodes to register new nodes from children but I simply cant wrap my head around it. I don't see how that is possible with React, but I'm certain that it's just me misunderstanding something or trying for too long.
Any help is appreciated!
TL;DR:
How do I manage state in trees so that I can access the whole tree and add/remove children to/from children and their descendants?
I tried to pass down an event from the parent through the whole hierarchy where every child would add its children but I'm not sure if that is correct since it seems really unclean.
If I'm understanding your question correctly, you want a way to traverse your tree. There are various ways to traverse a tree to generate a full depiction of its elements (to make a JSON object, for example), but I think you probably want to use in-order traversal. Here is a link with more details about some different tree traversal strategies.
If you're looking for a way to access a React component's children, you can read this article for inspiration.
I read through all the articles in internet. Still i cant understand and mind is puzzling me questions again and again that is
At the end of all the virtual DOM it is going to call the browser API to update the real DOM then how come it will be faster?
Is virtual DOM of React have special access to browsers core API's to modify?
I cant understand? Any resolves this questions Thanks in advance
Here is a talk given circa 2013 (v0.4.0) by the two guys behind React. They describe exactly how it works. Unlike data binding and dirty checking (Angular, etc.) React uses one render method that's called recursively. It then generates a long string that is a representation of the DOM. The concept is actually really simple.
https://www.youtube.com/watch?v=XxVg_s8xAms
Yes, you are right finally the task is to update real dom but the virtual dom comes in picture before updating the real dom. how ?
Suppose you want to update any/many element(s) in Dom tree element then there should be a mechanism to find which element(s) needs to be updated in real dom i.e the browser screen we see.
So this dom finding algorithm executed in virtual dom i.e a javascript copy of real dom(a html dom tree).
React creates two virtual dom, one from existing real dom and other from the changes made. These two virtual dom comparison saves time. The difference of this comparison used for updating real dom.
At the end of all the virtual DOM it is going to call the browser API to update the real DOM then how come it will be faster?
Any speed benefits come from minimizing the number of DOM manipulations that are needed and doing them all at once. The virtual DOM is react's way of calculating the minimum set of changes.
Here's what i mean by calculating the minimum set of changes: The page starts off looking one way, and then you want to make it look some other way. To get there, you're going to need to make one or more changes to the DOM, but there are many different ways you could do it.
A really bad way to update the page would be to wipe the entire document, and then rebuild every single element from scratch. Most likely though, you can reuse most of the page and just make a few updates to select parts of the page: add a div here; update a property there, add an event listener there. That's what you want: a small number of steps that take the old page and turn it into the new page.
Can anyone explain the difference between the virtual DOM and the Real DOM in React JS? I got the below answer but it is still not clear to me. Any Help would be highly appreciated.
A virtual DOM is a lightweight JavaScript object which originally is just the copy of the real DOM. It is a node tree that lists the elements, their attributes and content as Objects and their properties. React’s render function creates a node tree out of the React components. It then updates this tree in response to the mutations in the data model which is caused by various actions done by the user or by the system.
Virtual DOM is very easy to understand if you take an example of a lift which has a mirror inside it. Suppose, 4 people enters into the lift. Now, the mirror will reflect its appearance with 4 people. Again people entering into the lift will reflect the object of mirror. And same effect happens when people exit from the lift, the mirror object gets changes (increase, decrease, or even empty). So, in reality mirror has no real object, but it only reflects its presence with outer object.
Virtual DOM is similar in concept. It has no real DOM. It is just a copy of real DOM wrapped in a JavaScript object. Whenever the DOM changes, virtual DOM also changes.
For your interest, you may see the following post:
Rendered element in react
Learning Angular 2 and trying to understand when I should use a component input/output and when I should better update a service property (possibly attached with an EventEmitter if updates are needed).
I have a list of, say, tasks, and each list items shows various info and options for this list item. This list works in the way that only one list item is active, and the active one is on the top of the list. One of those options for each list item is to activate it (if it is not already active), but other components could also possibly change which is the active item.
I have a parent task component, list component and a list-item component (and some other related components), and in addition I have a task-service.
The main taskcomponent could use listcomponent (and something-realted component, many of the components used needs to know and possibly change the activeItemId), like this:
<list [(active-item-id)]=“activeItemId”></list>
<something-related [(active-item-id)]=“activeItemId”></something-related>
The listcomponent could use list-item this way (active is a pipe and also a property on item):
<list-item *ngFor=“#item of items | active”
(item)=“item”
[(active-item-id)]=“activeItemId”>
</list-item>
But since I have a task-service that contains various task related, I could on the service use the already existing activeItemId-property (that has an eventemitter), and all the various task-components could just get info (and be updated) via this property, instead of “sending” the property back and forth via various components via inputs/outputs.
When would it be appropriate to just use a service for something like this and when would it be appropriate to use input/outputs for components instead?
Got a great answer via Angular Google Groups:
Without reading your full explanation, I'd say use binding if
possible, otherwise use a shared service.
Binding is not possible when
- the two components aren't direct parent/children
- the component is added by the router
- the component is added by DynamicComponentLoader
If you share the data between several components at once it might be
easier to not use binding even when one or some of them are direct
children.
Thank you, Günter!
All:
I am pretty new to React.js, heard a lot about React virtual dom, but I kinda wondering what is the main difference between it and real DOM when deal with a simple case like change a style of a element:
Say I want to change the distance of a div to others, I can use jQuery for:
$("div#test").css("margin-left","10px");
And my understand about how browser does to the real dom is:
search down the DOM tree and find that node.
updating according style attribute( I guess it is CSSOM tree )
rendering the view
So my question is:
Is my understanding correct?
If it is basically correct, then what does virtual DOM do to improve the performance? Does not it just use a diff algorithm to compare what need to update in its light weighted version DOM tree and find that margin-left needs updating, and apply the same thing like in jquery to the real DOM?
OR
if it is not correct, could anyone give a little detail what heavy job does browser do to real DOM which React virtual DOM skip to enhance the performance?
I find a post mention 3 detail operation on virtual DOM:
What makes it really fast is:
Efficient diff algorithms.
Batching DOM read/write operations.
Efficient update of sub-tree only.
So comparing with this, does that mean in real DOM:
Not quite efficient diff algorithm or no diff algorithm(just update
everything)?
Single read/write operation like if I give 3 style updating to even same DOM element, the browser will look for that element down the DOM tree 3 times and update style?
Update whole DOM from the root(basically like dump the current tree and rebuild the whole DOM tree again no matter what part of the tree need update, and find the node and update)
Thanks
First of all, you are right with how the "real" DOM manipulation works.
React keeps an in-memory representation of the "real" DOM which we call the virtual DOM. Instead of traversing the "real" DOM for the node to modify, this virtual DOM is easily and quickly accessed therefore delivering update faster. Also, imagine a lot of changes in the DOM, traversing the "real" DOM would take a long time. This is one situation where the virtual DOM really excels.