I am having some issues with a Wicket ListPanel. The whole ListPanel is refreshed via Ajax from a filter that is defined on the same page. This schema works quite well under normal circumstances.
One part of the ListPanel is a component that needs some specific JS and CSS files for it's proper functioning. These are declared in the wicket:head section of the specific component.
When the page is loaded for the first time and the list has at least one item, everything works fine. However, when the list is empty when page is rendered, the child component of the ListPanel is never loaded and the CSS/JS imports are not considered. If, afterwards you refresh the DIV with an AJAX request, the wicket:head section of that component is not reloaded, so the Javascript code is broken.
My assumption is that Wicket will consider the wicket:head section during normal page render, but not when a component is updated via AJAX.
So, my question is, what would be a good approach to get the resources I need without having to push the imports up to a component that doesn't use the resources directly? I know pushing them up to other components or the page will do the job, but I don't really think it's clean, I like to have things where they belong, and if a component is the only one to use some resources, they should only be loaded there.
In your listPanel
#Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderOnDomReadyJavaScript("someDomReadyJSFunction();");
}
your JS should have a function to be called on domready, that will do the work in wicket 1.5.x
for wicket 6 check this
Related
It really scares me that I might want to know this thing so much. That's the whole essence of SPA (Single-Page Application). I am curious about Vue.js rendering pages. I will list some of my knowledge and If I'm wrong, please correct me. Things I think I know:
There's a which might be a tree-structure parsed from html.
Then, DOM RENDER TREE IS constructoted from css and that DOM-TREE
After that, rendering page means data is shown on the screen.
What about Vue.js? I know it has virtual DOM. If I change something with Javascript in Vue.js, the real change happens in virtual DOM because it's faster and then syncing with the real template happens. If all that is right(if wrong, please tell me) then my question is the following:
When I use Vue Router and click some link to change the page, When new page gets shown, beforeMount() is called, then if i click back button to go the previous page, beforeMount() is called also. When using Vue Router and back button, does page rendering happens again or it's saved somewhere and to make it faster, it gets all the html from cache? So If I go to some page, then click back or Vue Router link, and page rendering starts from scratch, why would it be fast?
In my opinion, page rendering happens when there's some data changed or it's the first time I am accessing that specific URL. For the second time accessing, if data has not changed, it doesn't render the page from scratch. What do you think ? Thank you.
I have got a website, that is lazyloading react scripts from different sources. For each script loaded, we provide a div with the name of the script as id. As soon as the script is loaded, it searches for the div with the id and renders the components.
As the site is displayed on a stationary tablet it does not reload very often and the memory footprint gets pretty big. Is there a way to completely unload a react script without reloading the website? Is there even a way to just unload any
kind of script? I guess the garbage collector is responsible for this, but currently its not even removing scripts / components that have unmounted a long time ago.
As I was searching for a solution, I found this thread about angular. I'm basicly looking for a way to do the same with react (Even tho I didn't test the angular solution).
Before removing the script tag and the container DOM node, you can use unmountComponentAtNode to allow React to do its cleanup.
ReactDOM.unmountComponentAtNode(document.getElementById('root'));
Use a design pattern that uses conditional rendering and check in the componentDidMount if either data is returned or the specific section is to be rendered.
I currently want to add some react components to my asp.net page.
It consists of various partial pages which are loaded into the page as well.
The problem I am facing is connected to partial pages, webpack and react. I am using webpack to generate a bundle which also contains all react components.
In one of these components which I take for example now, I am waiting for the window load event before I render the component on a div, which is part of a partial page.
However, considering I am loading the bundle on the .cshtml which also renders the partial pages, the window load function is firing before the partial page is loaded and therefore before the div is available.
React is therefore showing an error, mentioning that the target container is not available.
How can I get around this issue? Is there an javascript event I could use to wait for this target container?
one way is to call React mounting in the same place your mounting div is
<div></div><script>mount react</script>
or use onshow event
<div onshow=" ... call script " />
another option is in react to wait for div to become available and use setTimeout for waiting, I am not aware HTML has the event for specific div not loaded, as it cannot reference it
I have a page created using React. Up until now everything was working great. But now the page loads and as soon as the page is loaded all components freeze and I cannot interact with them. It is important to note that the browser is working fine and it is not the browser that freezes.
If it helps, I am using webpack to host the page.
Here is a sample.
Basically I have a component that is like a parent to all other components. The parent component gets data from a server and passes along to other components.
The parent also passes along methods that I can use to call from children component and interact with server again and this is basically the pattern through all the project. I have sadly no idea why it started freezing even though everything including styles loads perfectly. I just cannot interact with it and press buttons and such
One thing that can freeze things is if in the onClicks you do:
<button onClick={this.setSector('legal')}>
rather than:
<button onClick={() => this.setSector('legal')}>
I'm making a game using JavaScript, currently I'm using window.location = "somepage.html" to perform navigation but I'm not sure if that is the correct way to do it. As I said in the title I've choosed Blank App Template so I do not have any navigator.js or something like.
Can you guys tell me the best way to do it?
Although you can use window.location to perform navigation, I'm sure you've already noticed a few of the downsides:
The transition between pages goes through a black screen, which is an artifact of how the underlying HTML rendering engine works.
You lose your script context between pages, e.g. you don't have any shared variables or namespaces, unless you use HTML5 session storage (or WinRT app data).
It's hard to wire up back buttons, e.g. you have to make sure each destination page knows what page navigated to it, and then maintain a back stack in session storage.
It's for these reasons that WinJS + navigator.js created a way to do "pages" via DOM replacement, which is the same strategy used by "single page web apps." That is, you have a div in default.html within which you load an unload DOM fragments to give the appearance of page navigation, while you don't actually ever leave the original script context of default.html. As a result, all of your in-memory variables persist across all page navigations.
The mechanics work like this: WinJS.Navigation provides an API to manage navigation and a backstack. By itself, however, all it really does is manage a backstack array and fire navigation-related events. To do the DOM replacement, something has to be listening to those events.
Those listeners are what navigator.js implements, so that's a piece of code that you can pull into any project for this purpose. Navigator.js also implements a custom control called the PageControlNavigator (usually Application.PageControlNavigator) is what implements the listeners.
That leave the mechanics of how you define your "pages." This is what the WinJS.UI.Pages API is for, and navigator.js assumes that you've defined your pages in this way. (Technically speaking, you can define your own page mechanisms for this, perhaps using the low-level WinJS.UI.Fragments API or even implementing your own from scratch. But WinJS.UI.Pages came about because everyone who approached this problem basically came up with the same solution, so the WinJS team provided one implementation that everyone can use.)
Put together then:
You define each page as an instance of WinJS.UI.Pages.PageControl, where each page is identified by its HTML file (which can load its own JS and CSS files). The JS file contains implementations of a page's methods like ready, in which you can do initialization work. You can then build out any other object structure you want.
In default.html, define a single div for the "host container" for the page rendering. This is an instance of the PageControlNavigator class that's defined in navigator.js. In its data-win-options you specify "{home: }" for the initial page that's loaded.
Whenever you want to switch to another page, call WinJS.Navigation.navigate with the identifier for the target page (namely the path to its .html file). In response, it will fire some navigating events.
In response, the PageControlNavigator's handlers for those events will load the target page's HTML into the DOM, within its div in default.html. It will then unload the previous page's DOM. When all of this gets rendered, you see a page transition--and a smooth one because we can animate the content in and out rather than go through a black screen.
In this process, the previous page control's unload method is called, and the init/load/processed/ready methods of the new page control are called.
It's not too hard to convert a blank app template into a nav template project--move your default.html/.css/.js content into a page control structure, add navigator.js to default.html (and your project), and put a PageControlNavigator into default.html. I suggest that you create a project from the nav app template for reference. Given the explanation above, you should be able to understand the structure.
For more details, refer to Chapter 3 of my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition, where I talk about app anatomy and page navigation with plenty of code examples.