ReactJS/Electron/MYSQL : Query Callback takes ages - mysql

I'm trying to build a small app. I found some useful ressources which helped me a lot, but when it comes to problem solving, my (still) superficial knowledge hinders me from analyzing the issue correctly.
First of all I'm running a local database via xampp and successfully connected to it based on this article:
I made the function that encapsulates the whole connection/query/disconnection process a method of my React Component and I'm calling it in componentDidMount() like so:
componentDidMount() {
let current = this;
this.hasMounted = true;
this.getClients(function(rows){
if (current.hasMounted) {
current.setState({
clients : rows
})
}
})
}
The cool thing: It's working. The bad thing. It takes 10 seconds to complete this although my table has just 2 rows... Any thoughts on this?
UPDATE:
Resumed working on the app today and it worked perfectly... until it didn't. Might have to do with multiple restarting/hot reloading through npm? Strangely though restarting the PC didn't solve this, as I would have expected made the difference to yesterday...

Related

StoreContext.GetAppLicenseAsync().AddOnLicenses sometimes returns an empty list when the user has a license

I have an XBOX only app in the Microsoft Store that has been up for a while. The app has an add-on.
I use a very simple code to get the list of licenses in order to check if the user has add-on.
See below.
StoreAppLicense appLicense = await StoreContext.GetAppLicenseAsync();
var licenses = appLicense.AddOnLicenses.Select(item=> item.Value).ToList();
//Here I just save this in my log to see what is in the list
LogInfo("licenses: " + string.Join(',', licenses.Select(l => l.SkuStoreId).ToArray()));
Ok, so most of the time this code works fine. But there can be instances where the StoreAppLicense returns an empty list, even when the user HAS the license.
This has been a problem that has happened sometimes since I published the add-on, but was always fixed by reinstalling the app. Lately, even after a reinstall; the issue reappears.
What is worst, this even happened to me two days ago. I reinstalled the app and it worked fine; but after restarting the app it happened again. Then after some hours when I came back home it "solved itself".
I also have the suspicion that sometimes the StoreContext.GetAppLicenseAsync() method never returns and that causes the app to "hang".
Needless to say, customers get upset at me and give me bad reviews for something that is beyond my control.
What should I do in this situation? Can you even trust the StoreContext library?
Has someone seen this happening before?

Web page is really slow in Chrome when inspector is open but *not* profiling

In my Angular application, after introducing some more heavy usage of ngxs, I see my application has been come very slow when the inspector is open, but not when the profiler is running.
This has made it a little hard to figure out what's going on, but using the old conosle.profile method (adding an entry to Chrome's old profiler), I've narrowed it down a little - but I'm not at all more informed now than I was - just more confused.
So here's to hoping someone here can help me out!
I have some screenshots from the profiling to share, but unfortunately not much else.
First, a screenshot from the profile chart:
As you can see, there's a looooong time, where apparently nothing is really happening. Note in the console, that the bottom method (startObserving) only takes .12ms (according to console.time)
Going up the tree a few steps, we find Handsontable - this is what the function looks like, and some timings associated:
function Handsontable(rootElement, userSettings) {
console.time('Handsontable total time');
console.time('Handsontable create instance');
var instance = new _core2.default(rootElement, userSettings || {}, _rootInstance.rootInstanceSymbol);
console.timeEnd('Handsontable create instance');
console.time('Handsontable init instance');
instance.init();
console.timeEnd('Handsontable init instance');
console.timeEnd('Handsontable total time');
return instance;
}
// Timer outputs:
// This looks OK
Handsontable create instance: 10.864990234375ms
// Also this
Handsontable init instance: 1462.807861328125ms
// Wow, what??
Handsontable total time: 52664.875ms
It looks like the 2 methods called in the Handsontable constructor/function have a total run-time of <1500ms, but the total execution time is more than 52 seconds.
What in the world can be happening in those ~50 seconds of - as I see it - idle time?
Any help is really welcome, hints, suggestions, help to better debug!
Note: In Firefox, this is not an issue. I've tried in Chromium 67, 68 and 69 too - same issue. It's a problem in Chrome across all platforms (tested in Windows 10, Ubuntu 16,17 and MacOS latest-1,latest)

Angularfire2 valueChanges() returns data after I deleted it manually in Firebase

I am querying a subcollection in Firestore in an Angular6 Web App. On the first run, my function went through, but I was missing some information, so I had to delete it. I deleted the data in the subcollection manually in Firebase.
This is my query:
this.inviteSub = this.afs.collection('groups').doc(myGroup).collection<any>('invitations').valueChanges().subscribe(invites => {
console.log(invites);
});
When I execute my function on the client (Chrome) again, the valueChanges returns me the data that actually has been deleted.
I already tried a hard refresh by CTRL+F5 of the website. I also closed the browser. I also tried to unsubscribe when I at ngOnDestroy. But none of my efforts "cleared" up my 'invites'.
Can anyone help me how I "refresh" my browser / function / 'invites'?
UPDATE:
I still could not figure out what the issue causes, but I changed my App to Angular 6. So, I also changed this in my question.
I found a solution by myself. In my 'app.module.ts' I had the persistence enabled AngularFirestoreModule.enablePersistence() and changed it to AngularFirestoreModule

Nodejs on Server Ajax/http calls not reading new data Mongodb

I've recently started with pushing my locally tested Node,mongo, angularjs sites to live environments hosted on DigitalOcean.
I'm having inconsistency with ajax/http calls. on my Local machine, I am able to do http request and update an angularjs variable and this in return populates the html on the frontend. all works Great! now testing this on my server with same envireontment setup, the only time the variable load new data is when i refresh the page.
For example (not my actualy code):
Nodejs - app.js:
app.get('/getlist', requiredAuthentication, function(req, res) {
list.find({'username':req.session.user.username}, function(err,list) {
res.send(list);
});});
Angularjs - angular_app.js:
$scope.onClick = function (points, evt) {
$http.get('/getlist').then(function(response) {
$rootScope.list = response;});
};
Jade - home:
li(ng-repeat="row in list")
So like I said, this works perfectly on my local machine, but on my server I must refresh my page to load new data, it's as though my variable gets cached on the server.
Any idea would help.
Thanks.!
------- UPDATE - testing v0.1 --------
So after some intensive testing here is what I've found, but still no fix.
If I add new data via an http post, and I go look in my mongo db, I see the new data. Then when I click on the ng-click to retrieve the new data via HTTP, it doesn't return the new data, and is stuck on the old.
If I leave the page open for 10mins, and then click the button, it retrieves the new data, this is such a shlep.
Sounds like cache, but why des it work perfectly on my local?
When looking at the console > network > status. it is code 304, and this means nothing changed?
------- UPDATE - testing v0.2 --------
I've now tested the return data with a log in the console and I did the GET with ajax jQuery, and I'm getting the same issue/behaviour, it's stuck on the same collection of data, so my conclusion must be that node.js is causing the issues.
------- UPDATE - testing v0.3 --------
Okay so I've completely stopped mongo and switched everything to mysql using node-mysql. once again, on my local it works like a machine and on my actual server its laggy with reading new data.
I used Sequal PRO to access mysql and I started adding new entries to a table.
Opening my web url in the brower it Immediately showed the new entries. But after that, adding new entries or deleting entries only showed affect in 10mins or so.
So my conclusion is that Nodejs is caching like a mother, anyone know more bout this? am i really the only one every to experience this?
Try res.json for return data from node
app.get('/getlist', requiredAuthentication, function(req, res)
{
list.find({'username':req.session.user.username}, function(err,list)
{
res.json(list);
});
});
My conclusion to this issue was that port 80 was somehow caching the content of a page and will only load new data with a page refresh.
I upgrade Node and used latest Express. And I'm running my web app on a custom port, all is working now.

IMobileServiceSyncTable PullAsync doesn't return

I currently use Azure Mobile Services with Offline Sync and I it has been working fine. However I now have come to a problem I can't seem to debug. On the PullAsync it never returns, never goes to the Web API, it never errors, it just seems to be stuck somewhere and I don't know where.
IMobileServiceSyncTable<ResponseType> responseTypeTable = MobileService.GetSyncTable<ResponseType>();
await responseTypeTable.PullAsync(responseTypeTable.Where(c => c.CompanyId == companyId));
I use identical code elsewhere with a different type and it works well.
The only thing that happens is the Windows Phone emulator UI locks up, I can press buttons on the keyboard but the input or buttons are all frozen.
I get this on the Debug Output
The thread 0xb80 has exited with code 259 (0x103).
After a 5 seconds and that's about it. Breakpoints everywhere, nothing happening.
The method was in a Command (I'm using MVVMLight). When I call the function on the class initialization and just hold the value it works fine. There is obviously some bug that occurs when calling PullAsync on an event, in an async RelayCommand but getting the call out of there solves the issue.
I'll leave it at that unless anyone comes back with why it is actually happening. This is just a workaround at the moment.