Forem: Victor De Grandis

How to use React Query on Nextjs

Victor De Grandis — Wed, 15 Feb 2023 15:05:36 +0000

Introduction

React query is a tool for creating hooks for fetching, caching and updating asynchronous data repository.

Motivation

Fetching data from your backend is one of the most performance killers features of any frontend, and it really helps to keep a copy of the fetched data in the browser, but it's not always possible, or convenient to build a Redux store, so react-query is a good alternative for managing API results without having to do a lot of work for it, and without having to fetch it again every time you need it.
With react-query, you have a shared source for all components that use that data, with a cache and mutations for updating the state across your application.

As their docs say:

React Query replaces the boilerplate code and related wiring used to manage cache data in your client state and replaces it with just a few lines of code.

You can check their motivation on their page

Usage

First, you have to configure the provider QueryClientProvider like this:

// _app.tsx

import { QueryClient, QueryClientProvider } from 'react-query';

export default function App({Component, pageProps}) {
  const queryClientRef = useRef<QueryClient>();

  if (!queryClientRef.current) {
    queryClientRef.current = new QueryClient();
  }

  return (
    <React.Fragment>
      <Head>
        ...
      </Head>
      <QueryClientProvider client={queryClientRef.current}>
        <Component {...pageProps} />
        <ReactQueryDevtools initialIsOpen={false} />
      </QueryClientProvider>
    </React.Fragment>
  );
}

If you don't know what a provider is, visit the react docs.

ReactQueryDevtools is an integrated tool from react-query that helps tremendously with inspecting and debugging queries.

Secondly, you have to make a service, for example at /lib/services/getClientsService.ts

// /lib/hooks/getClientsService.ts

export async function getClients(): Promise<NetworkResponse<Client>> {
  return axios.get(`/api/clients`).then(response => response.data);
}

And finally, a hook for consuming the service and giving react query the retry options:

// /lib/hooks/useClients.ts

export function useClients() {
  const { data, status } = useQuery<NetworkResponse<Client>, AxiosError>(
    `/clients`,
    () => getClients(),
    {
      retry: true,
      refetchOnWindowFocus: false,
      refetchOnReconnect: false
    }
  );

  return { data: data, status };
}

Now you're good to go using the hook in every component necessary, like so:


export default function Clients() {
  const { clients } = useClients()

  return (
    <>
      <div className="flex flex-wrap mt-4">
        <div className="w-full mb-12 px-4 h-full">
          {clients && clients.length > 0 ? (
            <ClientsTable clients={clients} />
          ) : (
            <Spinner />
          )}
        </div>
      </div>
    </>
  );
}

And there you have it, it isn't hard at all to build and it has a very good performance.

Have a good day :).

How to use Hotjar JavaScript triggers on Angular

Victor De Grandis — Tue, 03 Mar 2020 19:30:02 +0000

JavaScript triggers are the most useful feature for using Hotjar HeatMaps in one page applications, because without that you can't create HeatMaps on dynamic content or modals, dropdowns, etc.
So i will show you how i made it work on an Angular project.
I'm making the assumption that you already have an Hotjar account and initialize a project.

Include Hotjar in your project

First we need to include the tracking code in our index.html

<!-- Hotjar Tracking Code for https://yourpage.com/ -->
<script>
   (function(h,o,t,j,a,r){
       h.hj = h.hj || function(){ ( h.hj.q = h.hj.q || []).push(arguments) };
       h._hjSettings = { hjid:xxxxxxx, hjsv:x };
       a = o.getElementsByTagName('head')[0];
       r = o.createElement('script'); r.async = 1;
       r.src = t + h._hjSettings.hjid + j + h._hjSettings.hjsv;
       a.appendChild(r);
   })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
</script>

With that we already have the hj function on our window object.

Hotjar Service

Now my goal was to make the access to the hj function reliable and mantainable across the Angular aplication, so i made a service:

@Injectable()
export class HotjarService {
  public getInstance() {
    return window['hj'] = window['hj'] || this.getHotjarQueue(); 
  }

  public trigger(eventName: string) {
    try {
      this.getInstance()('trigger', eventName);
    } catch (err) {
      console.error(err);
    }
  }

  public vpv(url: string) {
    try {
      this.getInstance()('vpv', url);
    } catch (err) {
      console.error(err);
    }
  }

  private getHotjarQueue() {
    return function () {
      (window['hj']['q'] = window['hj']['q'] || []).push(arguments);
    };
  }
}

Here we have the trigger function that allows us to register a new HeatMap, and the vpv function that register a new virtual page. The getInstance and the getHotjarQueue expose the window.hj if available to the service.

Conclusion

Making this little wrapper to the windows.hj we can make the use of Hotjar a lot more readable and mantainable in a big project. Using the function directly from the window object in frameworks as Angular is dangerous because of side effects and untraceable errors.

How to store data in SharedPreferences

Victor De Grandis — Tue, 04 Feb 2020 13:24:36 +0000

I will be showing a simple but very useful way to store simple data for preferences on your Android app.
For that i'll be using SharedPreferences, which is in Android since the API v1, so there're no restrictions of versions for using it.
SharedPreferences lets you store key-value pairs of primitive data types, and read them in any place of your app, being stored in persistent XML files.

Storing preferences

First, of course, we have to import the interface:

import android.content.SharedPreferences;

Then, we can use it:

SharedPreferences prefs = this.getSharedPreferences("MyPrefs", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = prefs.edit();
editor.putString("folder", folder);
editor.putString("route", route);
editor.putString("name", name);
editor.putLong("modified", modified);
editor.apply();

Here what i'm doing is starting a new preference store under the key "MyPrefs", if i don't have one already its created.
On the second line i'm initializing a SharedPreferences editor, which allow us to modify the prefs object using the methods putString(), putLong(), putInt(), putFloat(), putBoolean() or putStringSet(). According, obviously, to the type of values you want to store. In my example i only need to store a few strings and a long value.

After adding the values i needed, i call the apply() method, which store the modified SharedPreference objects in the persistent XML files.
The Editor provides two methods to commit the changes, one is the used above, and the other one is commit(), the main differences are that apply() is asynchronous and don't return any value. If you need to know the result of the transaction you can use commit() that returns a boolean with the status of the write in the persistent storage.

Reading preferences

The reading process is even easier:

SharedPreferences prefs = this.getSharedPreferences("MyPrefs", Context.MODE_PRIVATE);
String folder = prefs.getString("folder", null);
String route = prefs.getString("route", null);
String name = prefs.getString("name", null);
long modifiedDate = prefs.getLong("modified", 0);

Here the only new methods are the getters, that correspond to each put that i enumerate before. The only difference is in the second argument, that is a default value for the variable to take if the key is empty in the stored preferences.

Conclusion

This is a very straight forward way to store some persistent data like user preferences or some state of the app without having to manage a database or something more complex.

How to do dynamic imports on AngularJs

Victor De Grandis — Mon, 03 Feb 2020 12:11:21 +0000

Supose you have an AngularJs app and you use a lot of different libs for different features in your project. You don't have to load all the code at once in the first paint of the page, and download it even if is not used.
Here i pretend to present how to delay the loading of libs until is really needed, or not download them at if is not.
In my project im working with AngularJs, but with typescript, so im using babel-loader and ts-loader inside my webpack setup.

Tools

I used the webpack plugin babel-plugin-syntax-dynamic-import, that allow webpack to separate the code when we write an import() in our source and put it on a different bundle.

Setting typescript

Typescript with a default configuration (targeting es2015) doesn't allow to have imports() beneath the code, it wants them on the first lines of the file, so we have to set "module": "esnext" on our tsconfig.json so typescript can undestand imports

Configure Webpack

Our webpack config must declare the syntax-dynamic-import beside the babel-loader:

{
    test: /\.ts?$/,
    use: [
        {
            loader: 'babel-loader?cacheDirectory',
            options: {
                plugins: ["syntax-dynamic-import"]
            }
        },
        { loader: 'ts-loader' }
    ]
}

This allows the babel-loader to interprate the import() on the middle of our code, and what Webpack does when reachs one import statement is creates a new bundle with the library you are trying to import, so the lib code is not loaded in other bundles, only on this separate one.

Using imports in your code

Now its all ready to put use the lib we need in our code:

import("XLSX").then((XLSX) => {
  var ws = XLSX.utils.json_to_sheet(data, { header: colHeaders, dateNF: 'dd/MM/yyyy hh:mm' });
  [...]
})

Here im using the import as a promise so its downloaded first, and then run the code where i needed it (it can be treated as a async/await too)
In the import i declare that i need the "XLSX" lib (which lets you export a grid to a .xslx file), and then i used it as always inside my .then() statement.
And using the app we see how chrome download the bundle only when the code is reached:

If i need another library at the same moment, i can chain promises (or asyncs if i wish):

import("XLSX").then((XLSX) => {
  var ws = XLSX.utils.json_to_sheet(data, { header: colHeaders, dateNF: 'dd/MM/yyyy hh:mm' });
  [...]
  import("../../node_modules/file-saver/FileSaver.min.js").then((fileSaver) => {
      fileSaver.saveAs(new Blob([s2ab(wbout)], { type: "application/octet-stream" }), options.exportarExcel + ".xlsx");
    });
})

In this example i'm using FileSaver to save the actual file im generating with XLSX, its a lib i don't need anywhere else, so i only downloade it in my code in this exact moment, and free the rest of my app from its weight.
I can reference XLSX as XLSX in the import statement because is declared as an alias in my webpack, if you dont have it you can use the url as in the FileSaver example.

Naming chunks

Thats good enough, but sometimes life is not as easy and you need to put more cod inside the same chunk, or you need to use the lib sometimes as static and sometimes dynamically, so for that is very useful to name the dynamic bundle:

import(/* webpackChunkName : "xlsx" */ "XLSX").then((XLSX) => {
  var ws = XLSX.utils.json_to_sheet(data, { header: colHeaders, dateNF: 'dd/MM/yyyy hh:mm' });
  [...]
})

This way webpack will generate a separated bundle when reaches this code, but it won't be a unnamed javascript, but named xlsx.js, so if you need it anywhere else you can reference it:

Conclusion

The first paints of every application are the most important ones in loading and performance, so every byte we can save worth our time.
But with so many cool features our applications can have now with the greate amount of libs out there, we don't want neither leave features aside because of their weight nor punish the first paint for it, and we don't need to if we use the right tools to manage correctly the loading.

How to parallelize webpack loaders

Victor De Grandis — Sat, 01 Feb 2020 17:27:55 +0000

Runing webpack on a big project can be an agony for developers and can delay the production builds and CI if is not treated properly.

My aim here is to present how you can parallelize the webpack loaders and reduce the times to just seconds.

Motivation

Working with a very big project built on angularjs (a monolithic with 5+ products inside) and with a custom webpack configuration that managed a lot of different file types, the building time of the app was around 7' only for webpack tasks.
So i decided to parallelize the most heavy loaders (like typescript and html) and reduce the struggle of the team and the cost of the builds.

Tools

For the speed check of webpack work, i used, and highly recomend SMP. With this package you only need to wrap your webpack object and it messures the times it takes for each loader to finish.
For the parallelization i used HappyPack. Which allows to set certain number of threads for every loader to work.
So each loader can transcript the

Original webpack config

The following configuration for webpack rules worked ok, did the job, but with such a big amount of files it took so long to finish.
Here we have js, ts, css, html, scss, icons and image types to be packaged by webpack (js and ts are separated because of the necessity of using the plugin "angularjs-annotate" for production):

module.exports = smp.wrap({
    [...],
    module: {
        rules: [{
            test: /\.ts?$/,
            use: [
                {
                    loader: 'babel-loader?cacheDirectory',
                    options: {  
                        plugins: ["angularjs-annotate", "syntax-dynamic-import"] 
                    }
                },
                { loader: 'ts-loader' } 
            ]
        },
        {
            test: /\.html?$/,
            loader: 'html-loader'
        },
        {
            test: /\.css$/,
            use: [ 'style-loader', 'css-loader' ]
        },
        { 
            test: /\.scss$/,
            use: [{ loader: "style-loader"  }, { loader: "css-loader" }, { loader: "sass-loader" }]
        },
        { 
            test: /\.(woff|woff2|eot|ttf)$/,
            loader: 'url-loader?limit=100000'
        },
        { 
            test: /\.(png|jpg|gif|svg|json|xml|ico)$/,
            loader: 'file-loader'
        },
        { 
            test: /\.js$/, 
            exclude: /(node_modules)/,
            use: {
                loader: 'babel-loader?cacheDirectory',
                options: { 
                    presets: [['es2015', {
                        "targets": "> 0.25%",
                        "useBuiltIns": "usage"
                    }]],  
                } 
            }
        }]
    }
})

Measured with smp it showed that the most expensive loader was ts-loader (almost 7 minutes), having to manage a lot of files from the project. So is the first to work with.

Parallelizing

So incorporating HappyPack to webpack is very straight forward, first you have to include a HappyPack instance with the plugins:

plugins: [
    new HappyPack({
        id: 'ts',
        threads: 2,
        loaders: [
            {
                path: 'ts-loader',
                query: { happyPackMode: true }
            }
        ]
    }),
    new HappyPack({
        id: 'babel-ts',
        threads: 2,
        loaders: [{
            path: 'babel-loader',
            happyPackMode: true,
            query: {
                plugins: ["angularjs-annotate", "syntax-dynamic-import"],
                cacheDirectory: true
            }
        }]
    })
]

Here we have an id property that will bind the plugin instance with the correspondent rule, the number of threads wanted, and the loaders to be parallelized. I only used 2 threads for each instance because testing it it didn't change the performance when i incremented the number of threads.
Here i have 2 instances of HappyPack because i wanted to parallelize both loaders in my ts rule, one for ts-loader, and one for babel-loader (needed for the angularjs-annotate and dynamic imports in production).
After we define our plugin called 'ts', we have to modify the rule:

{
    test: /\.ts?$/,
    use: [
        { loader: 'happypack/loader?id=babel-ts' },
        { loader: 'happypack/loader?id=ts' }
    ]
},

So now, when webpack wants to work with the rule correspondent to the .ts file type, it will be looking for an HappyPack instance with the passed id, and run it according to its configuration.

Results

Parallelizing the ts-loader, the time it took to run accordingly to SMP changed from 7 minutes, to only 30 seconds. Which is a very significant proportion.
The costs of building the app reduced a lot, and (most important) the development team was very pleased with the less time waiting for each run.
This same work with the ts-loader was replicated also in other loaders, as the html-loader.
With loaders that doesn't parse too many files it doesn't make such difference and can be a waste of time, so the rest remains on a single thread.
Also it has to be said HappyPack doesn't work with all webpack loaders as some loader API are not supported.

Conclusion

Using this very simple and very straight forward tool you can reduce significatly the times of you webpack tasks and benefit the budgets and the dev team.