DEV Community: Franco Sirena

Lazy loading, why? when?

Franco Sirena — Thu, 16 Jul 2020 15:19:27 +0000

The answer to "Should I use lazy loading now?", like so many technical questions, comes down to "It depends." It isn't great to hear that, but oftentimes, unfortunately, that is exactly the answer that makes the most sense.
That said, I am going to try to elaborate on why and when to use lazy loading, but, in the end, the decision will always demand a certain level of understanding about the technical environment and surrounding ecosystem.

Why

Starting with the why, well, the why is quite simple: You don't want to bombard your end-user with a massive JS file containing every little aspect of your app, especially if they won't ever get to those aspects of the app. With that in mind, you have to decide what really matters to a regular user when they login to your app, what is the typical workflow that also coincides with a reasonable bundle size (If we wanted to be more precise, it's worth noting that this will depend on your targeted device(s)). The reasoning behind this is this: You want to make your first load as fast as possible for your user.

When

With those things in mind — the user-flow, which page goes to where, and what they see on each of them — you start scraping the "top-level" components of your app, and as easy as it can be you can totally create a separate bundle this way, containing each of these "top-level" components. Cool, you have a starting point, now what?
Well, now you can start to analyze the dependency tree of each component, meaning, look at everything that your component relies on, externals and internals, check if you have shared dependencies with most of your app or if you are adding new ones on that tree node. If you find yourself in a situation where your component, and just that, is using a bunch of new dependencies, well, it may make sense to isolate that bundle too. If not, let's say for the sake of example that it uses a package that is utilised everywhere, it utilises components that are utilised everywhere, well then, a separated bundle for just that piece is not justified because, once that component is split off from its dependencies, it will probably end up being something like a few bytes.
Remember that you can use techniques like prefetch to download bundles in the background, which can expedite things a lot on views that have too much going on. That technique allows you to download bundles without degrading the overall performance, and though it will indeed consume bandwidth, the overall effect is worth it when you know your user is going to need it very soon.
With all that in mind, when I am trying to decide if I should lazy-load or not, I start by analyzing the bundle size, checking if something I did significantly increased it, checking if a new page is causing much harm to a "top-level" component, and, if so I start to analyze what I can lazy load/what is unnecessary for the first load. Remember, lazy loading every little piece is not a good idea, because that creates a waterfall effect that can even degrade performance rather than improve it, e.g., one bundle downloads the other and the other one makes an API call and then downloads another yada yada.. You get the idea.

Always check your network tab to see when your bundles are starting the download
Check the timing of your requests, see if you can make them happen earlier ( if they are extremely necessary )
Check if your bundles actually make sense, e.g., making one extra request to download 40 bytes doesn't yield many benefits.
Make sure your tree shaking is working, taking special care to check your vendors' bundle, to guarantee you are not getting them all at once even though you're only going to use like 30% for the first load.
Put in place some metrics to monitor your loading time; that will certainly help to detect when you introduce slowness. I hope these tips and tricks are helpful, but I caution against premature lazy-loading and recommend some level of understanding and analysis of the app in question before applying lazy-loading everywhere. When in doubt, look at your bundle, it will tell you what you need to know.

Cheers :)

Creating API files based on shared state

Franco Sirena — Sun, 01 Sep 2019 11:35:41 +0000

This past week I had an interesting challenge, take some regular methods, called APIs, that relied on state values to make request. Those methods used to just go straight to the store observable and do a getState() to access the latest state of redux (but, would they?).

Since I was in a saga of removing all direct access to state through store observable, I had to find a way to deal with such methods. It's kind strange to realise that those kind of files would make sense, since:

If you'r full down on redux, then, the place to do requests would be the middlewares, in our case, sagas;
If you have your requests isolated in there, there is no reason to have yet another abstraction called API;
If you'r relying on state for those calls, you should be using middlewares.

But, as React evolved and Redux too, there are pieces of the state, specially in such massive apps like ours, that should not be stored in the global state and could, or even must, be stored in the local state in a short lived memory. So, in order to keep the APIs centralised in a single place, we came up with those API files.

So, I had to come up with a solution to remove the direct access AND that could be used both, in sagas and in components, tricky.

And then it hit me, S E L E C T O R S :)

With them I could simply access the API in Components with mapStateToProps and do a yield select in sagas.

So, I created the so called APIgenerator methods, that would accept the state as input and, using createSelector to have some memoization, read all pieces of the state that the API relied on and return in the final method an object containing methods to be called inside of the consumer, something like this:

https://gist.github.com/FrancoSirena/94f956b9c4a2e1c380d2919b3c01c622

OBS: If your methods depend on different chunks of the state you could expose as many selector as you want to, having the final method return another function to be called in the Component, such as, (stateChunk) => () => fecth.

I tend to keep most of my state under a context or even in the component itself, but, there are ton of situations that we may need to store it in redux and even though react APIs are getting better and better, redux is one hell of a powerful pkg.

So, don't doom redux, use it carefully and most of all, know how to use it and how to take advantage of it

Thank you react-redux!!

Franco Sirena — Fri, 23 Aug 2019 16:35:50 +0000

From react-redux 6 and further, people won't be able to access store from outside of the Provider Context. I mean, they can still try and sometimes they think that they succeeded, BUT, the underlying truth is that they will be probably failing every single time.

As from the version mentioned and above, if you access the state from outside of the reducer context while doing an action, you'll see a really scaring error showing up. That should be in there ever since day 1 in Redux, but it wasn't and now it is, which will simply prevent people from doing risky stuff like exposing store in a variable to access it in components/methods without using a connect or a hook ( react-redux > 7 ).

In one of the apps that I work with, our team had the terrible habit of doing that. When I realised it was too late and that pattern was already spread all over the application, thankfully during react-redux migration those errors started to occur and I finally had a extremely powerful reason to convince people that it was wrong, and I finally could get rid of that extremely painful and risky anti pattern.

So, thank you react-redux for doing that! Icing sugar is the store as prop deprecation, but, that shouldn't be even considered a breaking since no one should be using ( but, yes, we were using it too ).