I need to reload full tree with new parameters when an event is triggered (say a button is clicked) an item value is set and new item value need to be used in Tree SQL.
Tree nodes are not refreshing When I try to refresh tree region using "Refresh" action.
The tree widget supports a whole host of advanced operations. The problem is the apex team has never exposed these options to developers. Instead they chose to mimic the technique they used for the old tree. While that tree also supported far more than what they ever exposed...
The short of it is that with both versions the data delivered to the tree is a json-payload in the render of the page. The tree consumes this and renders the nodes. Because of the "static" nature of its data it can not be refreshed.
Long story short: sorry, the tree as generated by apex does not support refreshing. You'll need to reload the page.
Related
How is React's Virtual DOM able to only render a certain part of the DOM & keep the rest of the tree?
Not sure if I'm correct, but if I change content of a Div in a normal HTML file, I would have to refresh the page to see the changes, right? Meaning I would have to repaint the whole thing, recreate the whole DOM tree again. I can't just directly update "only" the Div element myself. I will need to refresh the page & recreate the whole tree.
I know what Virtual DOM is, how it compares new version to it's old, diffing & stuff like that. I also read the reconciliation document, but that didn't answer my question as well. What happens after React has the new Virtual DOM it needs to convert into the Real DOM?
What I'm trying to ask is: Essentially, React is just plain HTML & JS, having to end up as the real DOM. So how do they only update a Single Div element in the DOM instead of needing to reload the whole page? Because if we did that manually in HTML, the whole page would need to be refreshed to see changes & as far as I know, we can't just update one part of it ourselves like React does.
The short answer is that you don't have to reload the page to update the DOM tree. You can try this yourself by inspecting any element and edit its contents. React can also update the DOM in a similar way. It's instant as the contents are in memory and not saved on a file (which would need to be reloaded).
Example of a DOM update :)
You can update the DOM with javascript. the reason why you need to reload the page when you update a file and react doesn't is because when you load a page in the browser, the browser loads the page's files into it's memory/your ram executes the code (html, css and javascript). reacts code for updating the DOM is in the page's javascript.
However, if you change the html in a file, chrome doesn't have an idea so wouldn't know, hence you would have to reload the page for chrome to load the new page resources into it's memory and execute whatever code there is.
Came across below statement in one or other form on google
Each time the underlying data changes in a React app, a new Virtual
DOM representation of the user interface is created.This is where
things get interesting. Updating the browser’s DOM is a three-step
process in React.
Whenever anything may have changed, the entire UI will be re-rendered
in a Virtual DOM representation.
The difference between the previous
Virtual DOM representation and the new one will be calculated.
The
real DOM will be updated with what has actually changed. This is very
much like applying a patch.
I am new to React and would like to understand above how above three points used to to work in pre-React Era say in jQuery (or native JS).
jQuery
HTML was constructed on server side, sent back to browser. Browser will parse, render, layout and paint it.
Say any new DOM element is created or hidden either on some user event or on load.
Will jQuery recreate the complete DOM? From third point stated above looks like React just update the DOM for only the part that has been changed but other system (primarily jQuery or native JS) will recreate the complete DOM. Is that correct?
Is the third point true only for DOM changes or even when state of any UI component changes like filling the text box/dropdown etc?
Will jquery recreate the complete DOM ? From third point stated above looks like React just update the DOM for only the part that has been changed but other system(primarily jquery or native js) will recreate the complete DOM. Is that correct?
jQuery
No, jQuery doesn't recreate the DOM. Instead it navigates the DOM tree with selectors provided to make the appropriate changes. This makes jQuery very similar to React, but its performance issues come with the way the code was designed and it's heavy usage of the facade design pattern. This is normal for any larger library that needs to support multiple browsers like Chrome, Firefox, Opera, etc.
Angular 1
A framework that used to repaint the entire DOM was Angular 1. The client would make some changes, and rerender whenever $scope.apply or $scope.digest was called. This, combined with a huge number of listeners on large pages for two way data-binding was one of the big reasons why Angular had to undergo significant changes to stay competitive. Angular 8 is probably equivalent to React, but one has seen more adoption then the other.
React
React only updates the DOM that was changed. This is part of its "secret sauce". Along with its component centric architecture and early adoption of one way data-binding, it's seen a lot of success. Arguably React is starting to get more bloated since there's such wide adoption. This is normal for any project that gets mainstream usage. It's only a matter of time until people view React as a ton of performance problems and we'll create a new framework.
Alternatives
There are even faster frameworks than React, such as Elm lang. Nothing ever beats pure Javascript (e.g. document.querySelector()) since at their core, all frameworks use it. At that point you start hitting other trade offs such as lack of external libraries you can depend on, or difficulty in maintaining large front end codebases.
Is the third point true only for dom changes or even when state of any UI component changes like filling the text box/drop down etc ?
For jQuery or pure JS the third point is not true. There's a custom on-click handler of some sort that will run a function that makes a small change.
For something like Angular, that could be true if there are changes to scope that trigger a repaint. The same applies for React. If your submit button is supposed to redirect you to a completely different page, it will basically be repainting the DOM.
in react js in reander it create virtual DOM compare with browser DOM and update browser DOM. Rather than having virtual DOM why not to update directly in browser DOM.
Performance. Reading/writing to DOM is very expensive. It is much faster to calculate changes on JS data structure and then just do minimal amount of changes on real DOM. Except for some special cases you can avoid reading browser DOM alltogether thats why react is so fast.
Check this simple benchmark as you can see reading is not expensive. Writing is also not expensive but reading and writing is crazy expensive. (updateNode function does reading and writing)
Image is taken from this talk which I really recommend.
The DOM is made up of nodes that are rendered by your browser. As your application receives input from the user, it has to change certain nodes in order to show it's response (Ex- A button turning blue from red when the user clicks on it). Now, DOM is not good at doing anything smart. So, any time anything changes, it will re-render every node from scratch. This is a costly process.
React adds the brains to DOM by telling the DOM which node to render and which node to leave as it was. (Ex- Except the button, everything else in the UI should not change). This is done by storing the state of your DOM in JS in the form of nested objects (Forming a tree like strcuture). Changes to specific parts of this object will help React figure out which part of the DOM tree actually needs to be re-rendered. This is done using the concept of immutability which is very nicely explained in the ReactJS docs. So it basically diffs the new object with the old one and tells the DOM to make changes to specific nodes ONLY, thus improving performance by many folds.
I'm just playing around with backbone.js and some jQuery magic to prepare for some upcoming projects.
One test case contains a table whose rows are rendered by a backbone view. They get perfectly re-rendered on value change. Afterwards the whole table is sorted by an jQuery plugin (Animated Table Sort), rows move to new positions. In fact, this process works once, but the next time, rows appear twice, everything ends up in chaos.
Is it possible, that the link between DOM element and backbone view can't handle such an change? Are there any workarounds?
When you're developing with a Model/View framework like backbone.js or knockout.js, I find that you need to re-arrange your thinking and implementations to make changes to what is diplayed (like sorting) to the Model, and not allow them to happen in the view (like using a jquery plugin).
If you do end up using a view-side script to do something fancy (animations are a good example), then it is up to you to make sure the model is updated correctly, either by disabling or extending the binding.
Also note that according to the documentation, that animated sort plugin removes your table rows from the DOM, adds them to new DIVs, animates them, removes them from the DIVs, and restores them to the table. I'm wondering if after this is all done, backbone has lost track of those TDs, and when it re-renders after the change, it's just adding a new set since the last set is 'gone'.
Thanks for your answers. Indeed, the table sorter does a lot that makes it difficult fpr backbone to maintain bindings. I've switched over to the great Quicksand plugin which uses a hidden list to animate changes in another (visible) list. Fits better to backbone.js.
Your collection maintains an order for your models, and therefor your corresponding views. If an outside force (like a jQuery table sorting plugin) modifies the order of the views, this change is not inherently reflected in the Backbone collection, so things are quickly out of sync.
Also, if the table sorter clones elements and removes the original, Backbone would likely lose track of the views and end up recreating them.
Here's the task at hand. I need to implement a fully client-side tree that will work finely with permalinks and back/forward buttons for navigation.
E.g. I open a page with such tree control, expand some nodes, then press back and it collapses the last expanded node, then press forward and it expands the subject node. Finally I copy the url of the page and send it to my colleague - she clicks the url and the tree gets its nodes open to reveal the same tree structure that I see on my screen.
I'm looking for a JavaScript tree control that would fit the following list of requirements:
(Mandatory) Support for asynchronous node retrieval.
Possibility to hook into expand/collapse events to invoke custom logic that will serialize tree state into url anchor.
API for programmatic expanding/collapsing of given nodes, so that I don't have to emulate clicks when deserializing tree state upon pageload.
I've already had some experience with jsTree and jQuery treeview.
The problem with jsTree is that it uses <a> tags to render nodes, which messes up url anchors on click. After a couple of hours I've managed to migrate it to <span>'s, though my solution works only in Firefox. Not as good as I'd like.
Another thing happened when I tinkered with jQuery treeView. At first I was embarassed by its "not in active development" status, though upon a second glance it appeared to be a simple yet powerful widget. The async demo looked excellent so I tried to reproduce it at my PC and with my data. But then I faced a weird bug - when my JSON service returned lazy nodes (i.e. ones that had hasChildren set to true), the treeview immediately expanded those and rendered the "loading" gif, though without loading anything. I tried to debug this glitch, but I'm really not that smart to understand how all those callbacks and aspects interact with each other. At least not within the time window I had.