I want to write an application using NestJS. But coming from PHP, I am very much used to the SSR approach of rendering views for the client. Now, by using JavaScript, I could technically ask the server to not completely navigate a page, but just load the <body> element of the sent output, and then embed that into - and overwriting - the current view. By what I can tell, initially, this would work as I would just app.$mount(...) on the initially sent HTML and have Vue hydrate off that.
But what if I want to implement this across multiple pages?
The idea is, that by using SSR, I get to keep basically all SEO related features and can reduce the initially loaded JavaScript by taking advantage of WebPack's lazy-loading feature. But when a user navigates from page A (initially loaded) to page B (subsequent load), I would like to just replace/update the current content and then load the bundle apropriate to that page and hydrate.
Is that possible, and if, how?
So far, I know I would have to unload the currently used bundle to remove all references to events and objects from memory, and then load the new bundle in, which I can then use to hydrate the received view. And this does not take into account that a menu bar might not need to be treated separately, since it will only have to have the current location updated with a .current class appended to the relevant menu item. I might be wrong here, but that is why I ask :)
Related
I am looking for a way to speed up my website by loading content that is not required to display the main DOM afterwards.
My webpage is loading 2.8MB of ressources where 879kB are actually transferred. (gzip)
I am aware of the possibility of loading only the required components, but if I do so, I'll have the same problem after a user clicks any link to another component.
Basically what I want to do is loading my main component and displaying the DOM immediately.
After DOM is loaded, I want to load the other components as usual.
Is there a NPM package that does this?
If not, how can I realise my desire?
Use lazy loading modules to load them only if needed. It will greatly decrease bundle size:
https://angular.io/guide/lazy-loading-ngmodules
Application should be split to separate modules and routing is modified not to load them eagerly
What you are describing sounds like server side rendering. You should check out Angular Universal.
https://angular.io/guide/universal
I am using Vue and Webpack in a large project and I am looking to optimize the loading of some components. I am already lazy loading my pages but I wonder if I can take a step further and dynamically load subcomponents inside those pages.
I want to load a subcomponent ("my-modal" in the exemple below) after the main component (the page) is rendered (to speed up the load time of the page). This sub-component is relatively heavy and means to be frequently open, but is hidden by default (its a modal). So my strategy is to load it right after the page is loaded but not with the page, so the page can load faster.
I came across vue's Async Components but I am not sure if it can help, does-it ?
Here is an exemple of what I was doing with an old school "static" import :
// page.vue
<script>
import myModal from "#/components/my-modal";
export default {
components: {
myModal,
},
}
</script>
Here is an exemple of how I am dynamically importing my sub-component (aka "async components") :
// page.vue
<script>
export default {
components: {
myModal: () => import("#/components/my-modal"),
},
}
</script>
I am registering my component locally (local registration), but I am not sure if its the best way, maybe its another question...
Importing dynamically will generate a new file, and this new file will only be downloaded when the user goes to that specific page, not when the user goes to /.
That increases load speed and decreases the bytes that the user has to download at the moment one access your site.
For all intents and purposes...probably not.
With today's modern devices, browsers, and Internet access, that component would have to be pretty significant in order to provide a speedup overall to page load. If it's just markup and code, I'd have a hard time believing that one component would even come close to approaching say, 700Kb in size (especially if minified and compressed). In all but the worst Internet connectivity, the browser is going to handle this with no problem at all, especially if the component is include in the main bundle for the site.
However, if your component does some heavy computational work upon arrival, then maybe there would be a speedup to loading it async (as the browser can "get on with" loading the page while waiting for the modal to arrive).
However however, most browsers only allow a number of XHR requests running to a single domain at a time (I think Chrome is 4 by default). Lazy loading a file would mean the requests made by the page itself take priority, but having more files to load over multiple requests rather than lumped into one may be overall slower.
However however however, browsers are excellent at caching these requests, so subsequent visits to your site probably wouldn't have this problem to consider.
Lazy loading modules really provides a speedup when you are able to lazy load entire sections of your site only when the user needs to access them, like on routes.
The final however, though, is that it's good practice to not burden browsers and mobile devices with needless bloat, and while lazy loading that module may not have a noticeable speed difference, it may overall be a decent idea depending on your needs and when you load it. If a visitor never needs to view the modal, and you load the modal when it's needed...there's a lot to consider, as that may cause a delayed UI but be better for an overall greater percent of your users.
If you're trying to make your site more accessible to those with poor Internet, and you know the modal will be used frequently, it'd be probably better to load it with the page because it's part of page functionality.
So i stumble on this component called lazyload.
What does it do and advantage and disadvantage of using it ??
Just curious about it because i watch some of john papa's videos and he keep mentioning it.
They idea of lazy load is that you only load something when you need it.
For example: at startup of your application you might not need a library to validate your form fields. (you only need it when someone actualy fills in a form and submits it).
Lazy loading makes sure its only loaded when needed.
The Plus:
Reduced start/load times & size.
Packages/data that are not used by the current user, will not be loaded.
Minus:
You have to have more seperate packages you can't minify and bundle them together.
More request to the server (because you can't bundle them).
could have a load on first use experience, the first time user does something the application needs to load some extra stuff.
conclusion & advice
So consider the size and the lifecycle of your application. If the application is small and you package all in one. probably the simplest approach would be to package everything in one. it's a bit of a longer load time, but after that the javascript gets cached in the browser anyways so it doesn't matter after first load.
Reasons you want to lazy load:
You want to be able to update seperate parts of the applications (thus not bundle it)
Application becoming problematically big. you want to cut it up in smaller parts.
You don't bundle your javascript files (great example here before angular was requirejs).
You have a lot of different types of users using the system each with completely different set of scripts.
Every page uses completely different set of javascript. (not likely when you use angular)
My team developed a django website with lot of pages that working completely without javascript or may be with the little jquery manipulation. We want try to use a react library to speed up our pages and add page navigation without full page reloading (we choose react because we implemented some SPA website with react and we like it). Also our pages should working with disable js.
I want to start with one page with 5 forms on it. If any form is submit then page is reloaded, data populated in fields is lost and it work slowly. I think to implementing sending data on ajax and change some html after server answer.
Every react tutorial is saying to write jsx components with html markup inside, convert it with babel to pure js and adding on page dynamically on page load. Or if you want to render pages on server you need to use standalone node server. But I already has a powerfull django template engine to render templates on server side, also I need to render templates with specific django things like multilanguage content, user variables etc.
Can I fully render page with django on server side and after loading say to react, that specific div it's a component with initial state and existing html markup? Or may be you can tell me another solution, without fully rewriting my website. Thanks.
Well, kind of. Every react app starts by specifying a root HTML element to render from. If you want to only render a portion of your website with react, just specify an element that covers the section that you want. Something like this:
ReactDOM.render(<MyMainComponent />, document.getElementById('myReactSection'));
However, in doing so, any existing HTML in there will be overwritten (https://facebook.github.io/react/docs/react-dom.html#render). So you'll need React to re-render the html that was already in there.
Also, you don't NEED babel to write react code, it's just very useful (in conjunction with webpack) to generate a single javascript bundle file to send over to the client that was originally written using the awesome new ES6 syntax (https://babeljs.io/learn-es2015/)
Need suggestion for a "treeview" (navigation) JS widget for a site that is:
Really large (up to 100,000 pages)
Static - all pages are generated from a external source, and the widget is embedded in every page.
To clarify: there are no frames, and no application server. All pages are generated and placed in a file system, each page is loaded independently, that means the treeview navigation will be loaded every time as well, so it should either use multiple files and load parts of the tree on demand, or to be super-efficient.
Commercial OK.
Use mashable kind of tree. Click here for detailed architecture
All serious JS tree widgets allow dynamic loading of children. The key issue here is that most of them will send the server a query like getChildren?parent=23674 and this won't do for your case.
Since the site is static, you need to generate files with descriptions of the branches of the tree in JSON format and request those from the server as the user expands nodes in the tree. You could also create files which contain the tree children as HTML but you will be more flexible when you send data to the client and use JavaScript to convert the data into HTML (plus you will save a lot of bandwidth).
Try Yahoo's TreeView. There is an example how to load data dynamically.
Noticed that none of the links are working. However there was one written for the exact same reason, which is efficiency on large number of data. You might want to check out PixoTree, and see if it's the right tool for you.
PS. I know it's an old question, but thought it might help someone who stumbles upon this question.