Our Global Presence

Canada
57 Sherway St,
Stoney Creek, ON
L8J 0J3

India
606, Suvas Scala,
S P Ring Road, Nikol,
Ahmedabad 380049

USA
1131 Baycrest Drive,
Wesley Chapel,
FL 33544
There are many ways one can structure an Angular app. But this is how we structure our applications for extensive flexibility, scalability, and small initial bundle size.
Fig-1: Preferred Directory Structure
Pic courtesy: javascript.plainenglish.io
Core directory is the place where you put singleton services, injection tokens, constants, app configurations, pipes, interceptors, guards, auth service, utils, etc. that will be used app-wide. If there is something which is specific to the application itself, deployment, CI/CD, API, and the Developer – chances are, it belongs to the core.
Fig-1: Example Core directory
Pic courtesy: javascript.plainenglish.io
Business features live in this directory. Make a module per feature. That module can contain components, directives, pipes, services, interfaces, enums, utils, and so on. The idea is to keep things close. So, a pipe, that is solely used in the Speakers module should not be defined in the global scope or inside Core. The same goes for any other angular building block required by this module only.
Fig-2: An example feature module
Pic courtesy: javascript.plainenglish.io
Components are prefixed according to the module name e.g.- if the module name is SpeakersModule, components would be named SpeakerAbcComponent, SpeakerXyzComponent etc.
Keep the component tree inside the directory flat. That means, if SpeakerListComponent is the parent and SpeakerListItemComponent is child, do not create speaker-list-item component inside the speaker-list directory. The prefixed naming should be clear to indicate such a relation. The idea is to be able to see what components reside in the module at a glance.
Feature modules can import other features and obviously from shared modules.
Consider shared modules a minWe library for your UWe components. They are not specific to a single business feature. They should be super dumb that you can take all the components, drop in another angular project, and expect to work (given the dependencies are met). You might already know that wrapping UWe components provided by other libraries such as Material, ng-zorro-antd, ngx-bootstrap, etc. is a good practice. It protects you from their APWe changes and allows you to replace the underlying library if required. Components in shared modules are a good place for such wrapping.
Fig-3: Example Shared Directory
Pic courtesy: javascript.plainenglish.io
Do not make a giant SharedModule, rather granularize each atomic feature into its own module (see Fig-3). Criss-cross import of atomic shared modules is allowed, but try to minimize as best as possible. To bring a flavor of a tiny library, you could even prefix the directories & modules with your angular application’s custom prefix (by default it is app ).
Pages directory is the most interesting part of this structure. Think of it like a sink, where feature modules fall into but nothing comes out (i.e- no exported member). In these modules, you do not declare any component other than the page.
Fig-4: Example Page Module
Pic courtesy: javascript.plainenglish.io
Page controllers have no business logic. They are merely the presenter and orchestrates components from business feature modules. Let’s say – home page. It will contain a header, a hero section, articles, comments, contact, etc. sections – all coming from respective feature modules!
@NgModule({ declarations: [HomePageComponent], imports: [ CommonModule, ArticlesModule, CommentsModule, ContactModule, HeadersModule, HomePageRoutingModule, ], }) export class HomePageModule {}
How a fictional home-page.component.ts might look like:
<app-header-default></app-header-default> <main class="container"> <app-hero-content></app-hero-content> <app-article-list></app-article-list> <app-comment-list-latest></app-comment-list-latest> <app-contact-form></app-contact-form> </main> <app-footer-default></app-footer-default>
They can take help from a page-specific service that combines data and state for that page only. You should provide such service to the page component and NOT in root. Otherwise, the state may persist even after you navigate away from the page because the page component will get destroyed but not the page service.
// home-page.service.ts @Injectable() export class HomePageService {} // home-page.component.ts @Component({ ... providers: [HomePageService] } export class HomePageComponent { constructor(private homePageService: HomePageService){} }
The most important purpose of page modules is that each module is loaded lazily to make the app performant and lite.
Pro-tip: If you define a single page component per module, then you can claim a further reduction in the initial bundle size. This practice also organizes all routes in a single source (namely AppRoutingModule) which is easier to manage. Then, your app-routing.module.ts file may look like this:
const appRoutes: Routes = [ { path: '', loadChildren: () => import('./pages/home-page/home-page.module').then((m) => m.HomePageModule), }, { path: 'home', redirectTo: '', pathMatch: 'full', }, { path: 'products/:id', // <-------- NOTE 1. Child route loadChildren: () => import('./pages/product-details-page/product-details-page.module').then((m) => m.ProductDetailsPageModule), }, { path: 'products', // <--------- NOTE 2. Parent route loadChildren: () => import('./pages/product-list-page/product-list-page.module').then((m) => m.ProductListPageModule), }, { path: 'checkout/pay', loadChildren: () => import('./pages/checkout-payment-page/checkout-payment-page.module').then((m) => m.CheckoutPaymentPageModule), }, { path: 'checkout', loadChildren: () => import('./pages/checkout-page/checkout-page.module').then((m) => m.CheckoutPageModule), }, { path: '**', loadChildren: () => import('./pages/not-found-page/not-found-page.module').then((m) => m.NotFoundPageModule), }, ]
Notes 1 & 2: Since route declarations are parsed top-to-bottom, be sure to declare child paths before the parent path. This will ensure lazy-loading chunks fetched correctly. Otherwise, if you define the parent route first, then visiting any child route will also load the parent route’s module chunk unnecessarily. You can see the difference in DevTools. Here is my experiment when We put parent route first (Fig-5.1) VS child route first (Fig-5.2)
Fig-5.1: When /products declared BEFORE /products/:id in routes config
Pic courtesy: javascript.plainenglish.io
Fig-5.2: When /products declared AFTER /products/:id in routes config
Pic courtesy: javascript.plainenglish.io
For more information and to develop web application using Angular, Hire Angular Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop web application using Angular, please visit our technology page.
Content Source:
Performance optimization of frontend applications plays an important role in the application architecture. A higher-performing application will ensure an increase in user retention, improved user experience, and higher conversion rates.
According to Google, 53% of mobile phone users leave the site if it takes more than 3 seconds to load. At the same time, more than half of the pages tested are heavy in terms of bandwidth it utilizes to download the required assets. Don’t forget your frontend application performance directly affects its search ranking and conversion rates.
We use the Vue JS framework for our frontend applications. The challenge we had with our frontend application was with the landing page, which was taking around 3.8 secs to load with 4.2 MB of resources to be downloaded. As the response time was quite high, it was challenging to retain the users.
This article would share some of the implementation changes which we did to improve the performance of our frontend application.
Image compression is really important when optimizing frontend applications. Lighter images get downloaded faster and load with less time as compared to larger images. By compressing the images, we can make our site much lighter and hence results in slower page load times.
WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters and web developers can create smaller, richer images that make the web faster.
WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25–34% smaller than comparable JPEG images at equivalent SSIM quality index.
WebP is supported by Chrome, Firefox, Edge, and Safari from version 14 and above. Please feel free to read more about WebP.
Pic courtesy: medium.com
It is evident that download time has reduced on applying webp compression.
Synchronous components loading is the process of loading the components with the import statement which is the basic way of loading the component.
Components loaded with a static import statement will be added to the existing application bundle. If code splitting is not used then the application core will become huge in size, hence affects the overall performance of the application.
The below code snippet is an example of static component loading of store and locale components.
import store from '@common/src/store' import locale from '@common/src/util/locale'
Asynchronous components loading is the process where we load chunks of our application in a lazy manner. It ensures that components are only loaded when they are needed.
Lazy loading ensures that the bundle is split and serves only the needed parts so users are not waiting to download and parse the code that will not be used.
In the below code snippet, the image of YouTube is loaded asynchronously when it’s needed.
<template> <lazy-image :lazy-src="require('@/assets/images/icon/youtube.png')" alt="YouTube" draggable="false" /> </template> <template> <img v-if="lazySrc" ref="lazy" :src="defaultImage" :data-src="lazySrc" :alt="alt" class="lazyImage" @error="handleError"> <img v-else :src="defaultImage"> </template>
To dynamically load a component, we declare a const and append an arrow function followed by the default static import statement.
We can also add a web pack magic comment. The comment will tell webpack to assign our chunk the name we provided otherwise webpack will auto-generate a name by itself.
const MainBanner = () => import(/* webpackChunkName: "c-main-banner" */ '@/components/MainBanner')
If we go to our developer tools and open the Network tab we can see that our chunk has been assigned the name we provided in the webpack’s chunk name comment.
Pic courtesy: medium.com
According to Dev Mozilla, code splitting is the process of splitting the application code into various bundles or components which can then be loaded on-demand or in parallel.
As an application is used extensively, it will have a lot of changes and new requirements with time it would have increased in terms of complexity, CSS and JavaScripts files or bundles grow in size, and also don’t forget the third-party libraries which we use.
We don’t have much control in terms of third party libraries downloads as they are required for our application to work. At least we should make sure our code is split into multiple smaller files. The features required at page load can be downloaded quickly with smaller files and with additional scripts being lazy-loaded after the page or application is interactive, thus improves the performance.
we have seen some of the frontend developers’ arguments, it will increase the number of files but the code remains the same. We completely agree with them but the main thing over here is the amount of code needed during the initial load can be reduced.
Code splitting is a feature supported by bundlers like Webpack and Browserify which can create multiple bundles that can be dynamically loaded at runtime or we can do the old school way where we can split the code required for individual vue files can be separated and loaded on demand.
Basically, third-party requests can slow down page loads for several reasons like slow networks, long DNS lookups, multiple redirects, slow servers, poor performing CDN, etc.
As third-party resources (e.g., Facebook or Twitter, or MoEngage) do not originate from your domain, their behavior is sometimes difficult to predict and they may negatively affect page experience for your users.
Using preconnect helps the browser prioritize important third-party connections and speeds up your page load as third-party requests may take a long time to process. Establishing early connections to these third-party origins by using a resource hint like preconnect can help reduce the time delay usually associated with these requests.
preconnect is useful when you know the origin of the third-party request but don’t know what the actual resource itself is. It informs your browser that the page intends to connect to another origin and that you would like this process to start as soon as possible. The browser closes any connection that isn’t used within 15 seconds, so preconnect should only be used for the most critical third-party domains.
As a part of best practices, we need to make sure we don’t have any commented code in JS or CSS files. It’s commented because we don’t want to use them, so better get rid of them as the commented code contributes to an increase in the size of the file.
As part of frontend application development, we might use some CSS frameworks but you will only use a small set of the framework styles, and a lot of unused CSS styles will be included.
According to PurgeCSS, it’s a tool to remove unused CSS. It can be part of your development workflow. PurgeCSS analyzes your content and your CSS files then it matches the selectors used in your files with the ones in your content files. It removes unused selectors from your CSS, resulting in smaller CSS files.
Also while importing anything from 3rd party libraries to run the application, we can use the tree-shaking mechanism that can avoid the unused CSS and JS code included in our 3rd party bundles. To analyze this kind of unwanted JS and CSS items from 3rd party libraries there is a tool called webpack bundle analyzer.
For more information and to develop website using Vue.js, Hire Vue.js Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop Website using Vue.js, please visit our technology page.
Content Source:
Before we get started, let’s first understand what we are building. The goal is to create a Vue.js component to display an image, but it should only download that image when it is in the viewport. In other words, if we have a large list of images, only the ones the user actually needs to see will be downloaded. This will speed up our apps.
Here’s the goals:
<img>
tagsWe know we will need an <img>
tag, so let’s start there. For accessibility purposes, images should always have an alt attribute, even if it’s empty. We can easily pull the alt attribute from the $attrs
or fall back to an empty string.
<template> <img :alt="$attrs.alt || ''" /> </template>
Now, something we need to fix is that we don’t actually want to set the image src attribute right away because that would cause it to download immediately.
Instead, what we want is a tiny transparent PNG that we can use as a placeholder for the image src
. Using a placeholder instead of an empty value will cause the image to take up space on the page while it waits to download the real image.
For this to work properly, we need to hijack the src attribute by expecting it as a prop
. We also need to tap into the <img>
width and height attributes to create a tiny transparent PNG with an HTML canvas, and export it as a computed property called dataUrl
.
<template> <img :src="dataUrl" :alt="$attrs.alt || ''" /> </template> <script> export default { props: { src: { type: String, required: true, }, }, computed: { dataUrl() { const { width, height } = this.$attrs if (!width || !height) return "" // create a tiny png with matching aspect ratio as img const w = 100 const canvas = document.createElement("canvas") canvas.width = w canvas.height = (height / width) * w return canvas.toDataURL() }, }, } </script>
Alright, so we’ve got a transparent image when the component lands on the page. Now we need to figure out how to set our src attribute to the real image when the component is in view.
For that, we will hook into the mounted lifecyle event and use Intersection Observer. Before we get to that, however, we need to do a little refactor.
We need a <div>
to wrap our <img>
(This will make more sense later). Divs and images behave slightly different, so we also nee a little bit of style to make sure it still behaves like a native <img>
.
<template> <div class=" app-img "> <img :src="dataUrl" :alt="$attrs.alt || ''" v-bind="$attrs" /> </div> </template> <script> export default { inheritAttrs: false, props: { src: { type: String, required: true, }, }, computed: { dataUrl() { const { width, height } = this.$attrs if (!width || !height) return "" // create a tiny png with matching aspect ratio as img const w = 100 const canvas = document.createElement("canvas") canvas.width = w canvas.height = (height / width) * w return canvas.toDataURL() }, }, } </script> <style> .app-img { display: inline-block; } </style>
Any attributes it receives should be bound to our tag and not the
<div>
. We’ll use v-bind
and $attrs
for the image, and tell the component not to add the default attributes to the root <div>
by setting inheritAttrs
to false.
we’re ready to implement the Intersection Observer for lazy-loading. we won’t go into too much detail on how Intersection Observer works, but in the mounted hook, we create an IntersectionObserver
that watches for the component (via $el
) to enter the viewport. When it does, we add an event handler to the image’s ‘load’ event, and assigns the image’s src attribute (which begins loading it). We also do a bit of cleanup work to the beforeDestroy
hook just in case.
<template> <div class=" app-img "> <img :src="dataUrl" :alt="$attrs.alt || ''" v-bind="$attrs" /> </div> </template> <script> export default { inheritAttrs: false, props: { src: { type: String, required: true, }, }, computed: { dataUrl() { const { width, height } = this.$attrs if (!width || !height) return "" // create a tiny png with matching aspect ratio as img const w = 100 const canvas = document.createElement("canvas") canvas.width = w canvas.height = (height / width) * w return canvas.toDataURL() }, }, mounted() { const { src, $el } = this const observer = new IntersectionObserver(([entry]) => { const img = $el.querySelector("img") if (entry.isIntersecting) { // Element is in viewport img.src = src observer.disconnect() } }) observer.observe($el) this.$once("hook:beforeDestroy", () => { observer.disconnect() }) }, } </script> <style> .app-img { display: inline-block; } </style>
Alright, our image starts on the page as a transparent PNG, and when it enters the viewport, it loads the real image. The next thing we need to make it better some placeholder while it waits to load.
We’ll add two props for the placeholder so it can either be a background color or a different (tiny) image. We’ll also add the placeholder as a <div>
which will be absolutely positioned over the entire component.
We need to know the size of the original image so that we can stretch our placeholder to the same size. If we don’t know the width and height (we’ll cheat and use the dataUrl
computed prop), we just won’t show the placeholder:
<template> <div class=" app-img "> <div v-if="dataUrl" :style="{ background }" class=" app-img__placeholder " > <img :src="placeholder || dataUrl" alt="" v-bind="$attrs" /> </div> <img :src="dataUrl" :alt="$attrs.alt || ''" v-bind="$attrs" class=" app-img__img " /> </div> </template> <script> export default { inheritAttrs: false, props: { src: { type: String, required: true, }, placeholder: String, background: String, }, computed: { dataUrl() { const { width, height } = this.$attrs if (!width || !height) return "" // create a tiny png with matching aspect ratio as img const w = 100 const canvas = document.createElement("canvas") canvas.width = w canvas.height = (height / width) * w return canvas.toDataURL() }, }, mounted() { const { src, $el } = this const observer = new IntersectionObserver(([entry]) => { const img = $el.querySelector(`.app-img__img`) const placeholder = $el.querySelector(`.app-img__placeholder`) img.onload = function() { delete img.onload if (placeholder) { placeholder.remove() } } if (entry.isIntersecting) { // Element is in viewport img.src = src observer.disconnect() } }) observer.observe($el) this.$once("hook:beforeDestroy", () => { observer.disconnect() }) }, } </script> <style> .app-img { display: inline-block; position: relative; } .app-img__placeholder { position: absolute; } </style>
A couple of other things to note are the in the intersectionObserver
. Once the main image has loaded, we want to remove the placeholder.
Theres a few more things we can do to make it a better experience.
We’ll accomplish most of this with CSS, but we do need one class added to the image once it has finished loading. And since we have a CSS transition, we also set a timeout to remove the placeholder. Any time we set a timeout, we also want to make sure we clear it when the component is destroyed.
For more Information and to build the website using Vue.js, Hire Vue.js Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft“.
To develop the custom website using Vue.js, please visit our technology page.
Content Source:
Let’s take a look at how you can leverage this feature in your application in order to improve performance and build a better experience for users.
As always, when building with components it’s useful to organize them in a collection using tools like Bit. Then you can share and use your components in any app you’d like, to speed development and keep your code DRY.
It is a new function in react that lets you load react components lazily through code splitting without help from any additional libraries. Lazy loading is the technique of rendering only-needed or critical user interface items first, then quietly unrolling the non-critical items later. It is now fully integrated into core react library itself. We formerly used react-loadable to achieve this but now we have react.lazy() in react core.
Suspense is a component required by the lazy function basically used to wrap lazy components. Multiple lazy components can be wrapped with the suspense component. It takes a fallback property that accepts the react elements you want to render as the lazy component is being loaded.
Firstly, bundling involves aligning our code components in progression and putting them in one javascript chunk that it passes to the browser; but as our application grows, we notice that bundle gets very cumbersome in size. This can quickly make using your application very hard and especially slow. With Code splitting, the bundle can be split to smaller chunks where the most important chunk can be loaded first and then every other secondary one lazily loaded.
Also, while building applications we know that as a best practise consideration should be made for users using mobile internet data and others with really slow internet connections. We the developers should always be able to control the user experience even during a suspense period when resources are being loaded to the DOM.
According to the react official documentation, you have webpack bundling already configured for use out of the box if you use:
If you are not, you will need to setup bundling yourself. For example, see the Installation and Getting Started guides on the Webpack official documentation.
you can create one yourself and make the changes below, the src folder of your application should look like this:
1. Artists.js
import React from 'react'; import './App.css'; import artists from "./store"; export default function Artists(){ return ( <> <h1>MTV Base Headline Artists 2019</h1> {artists.map(artist =>( <div id="card-body" key={artist.id}> <div className="card"> <h2>{artist.name}</h2> <p>genre: {artist.genre}</p> <p>Albums released: {artist.albums}</p> </div> </div> ))} </> ); }
2. Store.js
export default [ { id: "1", name: "Davido", country: "Nigeria", genre: "Afro-Pop", albums: "2" }, { id: "2", name: "AKA", country: "South-Africa", genre: "Hip-Hop", albums: "4" }, { id: "3", name: "Seyi Shay", country: "Nigeria", genre: "R&B", albums: "2" }, { id: "4", name: "Sauti Sol", country: "Kenya", genre: "Soul", albums: "3" } ];
3. Index.js
import React from 'react'; import ReactDOM from 'react-dom'; import './index.css'; import Artists from './Artists'; class App extends React.Component { render(){ return( <div className="App"> <Artists /> </div> ); } } ReactDOM.render(<App />, document.getElementById('root'));
4. App.css
.App { text-align: center; } h1 { padding: 30px; } #card-body { display: inline-flex; padding: 10px; margin: 30px 30px; border: 5px solid rgb(93, 171, 207); border-radius: 8px; background: lightblue; }
Now let us see how to use react.lazy and suspense to handle lazy loading of the artists component.
import { Suspense, lazy } from 'react';
const OtherComponent = React.lazy(() => import('./OtherComponent')); function MyComponent() { return ( <div> <OtherComponent /> </div> ); }
const Artists = React.lazy(() => import('./Artists')); function MyComponent() { return ( <div> <Artists /> </div> ); }
If the module containing the Artists is not yet loaded by the time my App component renders, we must show some fallback content while we’re waiting for it to load. This can be a loading indicator, brought in action by the suspense component. Below is the syntax for adding suspense component to react.lazy:
const OtherComponent = React.lazy(() => import('./OtherComponent')); function MyComponent() { return ( <div> <Suspense fallback={<div>Loading...</div>}> <OtherComponent /> </Suspense> </div> ); }
With our artists component, this becomes:
const Artists = React.lazy(() => import('./Artists')); function MyComponent() { return ( <div> <Suspense fallback={<div>Loading...</div>}> <Artists /> </Suspense> </div> ); }
Putting it all together, your index.js file should be like this:
import React, { lazy, Suspense } from 'react'; import ReactDOM from 'react-dom'; import './index.css'; // import Artists from './Artists'; const Artists = lazy(() => import('./Artists')) class App extends React.Component { render(){ return( <div className=”App”> <Suspense fallback={<h1>Still Loading…</h1>}> <Artists /> </Suspense> </div> ); } } ReactDOM.render(<App />, document.getElementById('root'));
On your localhost it should be really fast and you might not be able to spot the changes. You can however create a timer helper or just simulate a slower network that would be able to show you exactly how the changes occur in milliseconds. This can be done by:
pic courtesy: blog.bitsrc.io
Now you can refresh your browser and watch how lazy loading occurs..
pic courtesy: blog.bitsrc.io
Let us quickly add a small component that renders a header and see how the react.lazy function handles it with only one suspense component.
Create a performers.js file in your src folder and add the code below:
import React from 'react'; import './App.css'; export default function Performers(){ return ( <> <h2>These are the MTV Base Headline Artists...</h2> </> ); }
Then add the lazy component line in the index.js file and it should now look like this:
import React, { lazy, Suspense } from 'react'; import ReactDOM from 'react-dom'; import './index.css'; const Artists = lazy(() => import('./Artists')) const Performers = lazy(() => import('./Performers')) class App extends React.Component { render(){ return( <div className=”App”> <Suspense fallback={<h1>Still Loading…</h1>}> <Artists /> <Performers /> </Suspense> <strong> </div> ); } } ReactDOM.render(<App />, document.getElementById('root'));
This should now show the two lazily loaded components show up at once after the placeholder element from the suspense has been rendered.
pic courtesy: blog.bitsrc.io
This is quite unlike loadable which would have to render the loading element for each lazy component.
Note: React.lazy and Suspense is not yet available for server-side rendering. If you want to do code-splitting in a server-rendered app, Loadable Components is highly recommended. It has a nice guide for bundle splitting with server-side rendering.
For more Information and to build a website using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft“.To develop your custom website using React JS, please visit our technology page.
Content Source:
57 Sherway St,
Stoney Creek, ON
L8J 0J3
606, Suvas Scala,
S P Ring Road, Nikol,
Ahmedabad 380049
1131 Baycrest Drive,
Wesley Chapel,
FL 33544
57 Sherway St,
Stoney Creek, ON
L8J 0J3
606, Suvas Scala,
S P Ring Road, Nikol,
Ahmedabad 380049
1131 Baycrest Drive,
Wesley Chapel,
FL 33544
© 2025 — HK Infosoft. All Rights Reserved.
© 2025 — HK Infosoft. All Rights Reserved.
T&C | Privacy Policy | Sitemap