Sorry for the beginner question, but this is one where I'm a bit confused, and couldn't find documentation about. So I understand that if you subscribe to an observable, it can cause memory leaks if not unsubscribed from (for example in OnDestroy since I use mainly Angular). But, is it still a problem if you close the tab/page? As I'm aware of, the server which the app is on is not running it, just serves the frontend code to the browser, which then runs/loads it. So if you don't unsubscribe properly from an observable, it should still be "destroyed" after you close the tab that the app is running on, right? I'm not sure how the browser manages to store these exactly, so I'm not 100% in this, but it sounds logical to me, since apps are most of the time not running 24/7, it's only a problem where it does run all day long, right? (And yes I know we should unsubscribe everytime, I just ask this because of my curiosity).
Similar questions were asked before: with rxjs and angular, Is it necessary to unsubscribe for the subscriptions that happen only once in app component's onInit method?
Also here is an explanation in which the memory leaks are reproduced and why it was necessary to unsubscribe. I have taken the code present on that url and added it to stackblitz for reference. You can uncomment the code to unsubscribe the observable and refresh the url.
The conclusion that I understood from this is after closing the tab, there should not be any memory leaks.
Related
Is there a way to see unnecessary objects still in memory or pending network requests after the React component has unmounted?
If I can see that then I can handle that in componentWillUnmount().
Amir Saleem already mentioned Axios for handling requests. I don't think, that you need to be very concerned about garbage collection in JavaScript as the language interpreter does that for you.
That is a huge difference to C/C++ or some other low level languages where you are responsible for creating and deleting unused memory space.
Just put in the time to use good, tested and efficient algorithms in your code and let the Garbage Collector do the rest. Your whole component will be garbage collected if you're no longer using it.
If you really want an overview of the objects in your application, Firefox has a Memory feature in the developer console. It looks like that:
See more information on Memory Management. Avoiding Memory Leaks in NodeJS might also be interesting for you. Please see also the references on the bottom of the last page.
I want to migrate a big application from React Context API to Redux. The thing is, since is such a big task, I want to do it slowly and meanwhile be able to work on other things of the app (without adding things to the context).
Is it a good idea to migrate piece by piece and have both Redux and Context in the same app until I migrated everything? Or is it best to freeze the code and migrate it separately, and then work on new things?
I know it might depend on more variables but I want to get a general idea...
Only you would know the specifics of your app, but in general I don't think there's an issue with doing it piece by piece as you describe (migrating only some slices of state to redux to begin with.) You may find it turns out to be less of a headache to just do it all in one go though, but technically there's no reason you couldn't do this.
Obviously depends on how well you code base is currently structured.
We are about to do the same - i think our approach will be to add more tests to the context side, add redux concurrently with as flat state as possible then do one big move, the addition of redux with context could cause race conditions and other unknowns. Really big and scary change when the day comes to make the change, but hoping that we will have enough tests in place to manage. Wish we started with redux in the first place.
In an Assignment it was asked what is the first thing to do before testing changes done in JavaScript, after deploying an application. My answer was to clean the browser cache because the cached content may affect the new changes. I want to know whether it is a valid and a good answer or are there some things to do prior to that? Thank you
A word of advice, not all users understand the principle of clearing the browser cache to obtain changes. I suggest you to increment you'r javascript file instead of taking into consideration that users will clear their cache.
But before deploying a modification, I advise you to do some tests. Several types of test exist, you can look for example at unit tests.
What a vague question to be asked, however I personally think about how a real user would use the system when I test it. Therefore, would I trust the user to clear the cache / cookies etc everytime they used the system? No. I would expect to be able to either close the browser and open (or simply refresh the screen). As mentioned in another answer, 'cache busting' should be handled by the developer during the build process, for example by hashing the javascript bundle.
I used to get into a habit of opening dev tools all of the time and relying on the 'disable cache' toggle, however after a few times of getting caught out by real users seeing different behaviour that what i was seeing during development, I moved to ensure that the bundles weren't cached in both dev and prod.
Whenever I switch routes, I have noticed that Vue components in my application are never destroyed and only created (the # Deleted column is always 0 as I toggle between routes). To be extra clear, the number of new components created is always equal to the number of components displayed on that route i.e. NONE of the Vue components are ever destroyed and every component on the route is recreated when a route is revisited.
I've been researching to debug the problem and I know that the following are usually culprits of memory leaks in VueJS.
The use of a Global Event Bus and failure to unregister the callback. This is detailed clearly here. While I do use a Global Event Bus in some areas of my application, I'm also experiencing memory leaks on pages where I don't create any event listeners on the Global Event Bus, which leads me to believe that this is not the issue here.
Failure to manually clean up memory yourself when using 3rd party libraries, a problem outlined by the VueJS documentation. Again, I've been looking at memory usage on pages that do not use third party libraries and I'm still getting memory leaks on those.
There is one more potential issue I've come across which I don't quite understand. In this github thread, the OP said the following in regards to potential causes of memory leaks in VueJS:
So I made sure I wasn't doing anything stupid like storing a reference
to this on a Vuex Store...
Can someone please explain what the OP means here in regards to Vuex and memory leaks?
Additionally, what are some other potential issues that cause memory leaks in VueJS that I have missed that could be affecting my application?
How else should I be debugging my memory leak outside of using the Memory tab in Chrome devtools?
Memory is such a pain to debug and your logs look curiously similar to mine.
What i found was be careful of your logs :
console.log(vuecompoent) actually stores your component in memory and does not release it.
Also consider that I turned off vue dev tools as well, but im not sure if this was causing the issue .
Look into the retainers section . This may give you some insight.
The Express node.js server application I'm currently developing will sometimes go off into the void and stops returning requests. I very much suspect somewhere in it I am doing something that is ultimately skipping a res.end that I need to be doing.
Does anyone have any tips or tricks on how to best go about looking for where I'm missing the res.end (assuming that's the problem)? Is there anyway to view the currently open requests in real time in the node event loop?
When things hang up, everything is still running in that Express will still accept incoming requests. And, these requests are logged to the console via express.logger just fine. But, the request is never returned to the client and no error is being thrown.
Thank you in advance for your thoughts.
Follow-up:
There doesn't seem to be much documentation on node's debug mode beyond the raw API docs. I did find this article which seems to provide a good overview of several options. But, there doesn't seem to be the kind of thing I was thinking of for watching the event loop, something a la vtop's process list.
More Follow-up:
Yesterday, Daniel Hood published Debugging in Node.js stating that, "The state of debugging node.js apps has always been a bit unfortunate..." So, perhaps my question is not so silly as to merit down votes as it might seem. Anyway, in his next article he promises to cover some tools for debugging asynchronous operations.
I posted the last article you mentioned. If you need to debug async stuff, I'll be going over things like long stack traces (modules such longjohn), the try-catch module, and things like zones/domains. Hopefully those links will be of some help (might be a week before I write part 2).
However, for your particular issue, have you tried setting a breakpoint at some known location and stepping through the process? This way you can just watch how the app is executed, and maybe find where some function is returning nothing when it should be returning the req/res object.
If it isn't very reproducible, maybe some simple logging would be helpful.