After having spent hours trying to fix these warnings in a project I am working, on having tried everything including:
No anonymous functions.
No exports other than the default export in component files.
Capitalizing function names.
Deleting the .next folder.
Deleting the Inter Google Fonts import from index.tsx.
...I have just tried to start from scratch with a new pnpm create next-app (with typescript, eslint, src folder and no experimental app folder) and to my surprise the warnings are still there even in a fresh app:
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
event - compiled client and server successfully in 806 ms (165 modules)
wait - compiling /_error (client and server)...
event - compiled client and server successfully in 65 ms (166 modules)
warn - Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload
wait - compiling / (client and server)...
event - compiled client and server successfully in 104 ms (195 modules)
warn - Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload
The warnings/errors reappear even if I relaunch the app with no changes, the browser's console has no errors whatsoever and next does not give any indication of where the problem might be. The app actually compiles and works with no problem other than the warnings/full reload.
Is this expected and should be ignored or is there something wrong that escapes me? The only weird thing I can think of is that I develop in WSL2 (Windows 11) with an Ubuntu environment. Some people had problems in the past with Fast Refresh and WSL but they claim them to be solved since Next 12.
Related
I have a strange issue. I build my Meteor app and run it on android device using -
meteor run android-device --mobile-server=<my_aws_ip>:3000
When the app deploys immediately it connects to the server (and my javascripts etc works). After a few seconds, the page refreshs and none of the javascript callbacks work. Please help me debug this issue.
More information: If I change the client (and not the server), and deploy it, for the first few seconds, the changed client gets shown on the phone. After the first few seconds, the version which is present on the server is shown. So I think Cordova or Meteor is trying to fetch the client code from the server, which is breaking the app. Is there a way to prevent this behavior?
Even more data points -
My aws code does NOT have android and ios platforms installed. Because of this, I think the cordova plugins are not installed, causing a JS break somewhere.
Easiest fix I can think of is remove cordova autoupdate. This is being added by meteor-platform package. If I clone meteor-platform and comment out the cordova autoupdate, the app doesn't load.
Is there another way of removing autoupdate?
This sounds like you have a different version of your app deployed at the mobile-server address.
The local code is run in development mode. Your AWS one is likely in production mode (and may contain a syntax error).
When you run your app it sees the code is different and fetches the new/old (different) version with a hot code reload - hence the page refresh/flash.
To fix this, you need to find the syntax error in your code. It's best to view the ADB logger or run with meteor run --verbose android-device ....
This will provide a bit more information such as an Uncaught exception: cannot read .. of null error type error.
It's hard to say what the error is. The error prevents the rest of your code from executing. In production mode the entire project is one JS file. If there is an error of any kind half way along the file, the rest of the file will not execute.
Also, try loading <my_aws_ip>:3000 in your browser and watch for JS errors in the JS console.
You can also run it locally with --production to simulate a production build environment locally.
Enabling autoupdate but without a page refresh:
Reload._reload = function (options) {
console.log("Next load will load new version");
};
Does meteor run ios-device not build from scratch every time you run it? While meteor run ios serves the latest code, ios-device seems to serve the code that was built before. I have checked documents but haven't found anything related.
Are you building against a server other than your local server (i.e. something other than localhost).
If so, if that server has and old version deployed, it may be hot code pushing old client code when your mobile app starts up!
I've upgraded to 0.9.0.1 and that appeared to be smooth, an my meteor site works well.
However, on making a simple change to a template - literally changing a text inside a span - I get an error in the server console and the server then restarts.
server console log:
=> App running at: http://localhost:3000/
=> Client modified -- refreshing
I20140828-10:21:38.261(1)? Failed to receive keepalive! Exiting.
=> Exited with code: 1
=> Meteor server restarted
This appears to be related to new hotload process
When running your app with the local development server, changes that
only affect the client no longer require restarting the server.
Changes that only affect CSS no longer require the browser to refresh
the page, both in local development and in some production
environments. #490
What could cause this Failed to receive keepalive! error?
It seems from looking around the internet and on the IRC channel this could have one or two causes:
use of an incompatible package that got past the 0.9.x tests
some bad coding such a missed placed comma which when meteor compiles the application is forcing an error.
Or of course it could be both. Or something entirely different.
For me it was an incompatible package.
So I'm working on my Meteor project and all of a sudden everything stops working and my console reports that everything is 'undefined'. See screenshot. Why does this happen? Usually things will just randomly start working again after I reboot my machine or go get lunch.
This can happen if you have a hot code reload during when the page is loading from a previous hot code reload.
Your browser will eventually reconnect to the server, reconnect & refresh the page. In the case above it looks the the bit of Js that connects to the server doesn't get loaded to begin with (the DDP bit) so it doesn't behave as normal. If it reconnects it can fix it self by refreshing.
It's very hard to tell what exactly is causing it from the information you've given. I'd look at custom packages that replace core packages or some kind of of package you have that runs early on in your code that would stop the normal loading of a project.
If you're using meteor on windows there are a couple of bugs that do this too. I'm not sure how to get past those besides doing Ctrl+C to stop and then using meteor to start the project again.
UPDATE + SOLUTION ===============================
Sorry to be posting the solution here instead of in a comment, but something about my work's filtering doesn't allow the comment functionality to work for me.
I ended up using the -b 0.0.0.0 property in jboss to bind to all addresses, so I could try accessing machine A's server with machine B as the client, and vice-versa. I found that it always failed to load when running on machine B, whether or not I was connecting from A or B.
I started wireshark on a windows machine on the same network, and observed the TCP connection that was loading the webpage. I saw that the request for the .swf in the cases where it failed had a content length of 2 million or so, and when I right clicked the wireshark logs and selected "view conversation" or something like that, the size of the total conversation to get the .swf file was only 130,000. Looking at about:cache, that was about equal to what it ended up caching before saying "Done" on the page.
I ended up finding that there is a bug with the useSendFile property. (http://community.jboss.org/thread/148651?tstart=0). This causes it to only send part of the file if you are running low on kernel memory. Using useSendFile="false" in our server.xml has seemed to resolve the problem.
==================================================
Original Problem
I have a JBoss (5.1.0.GA) application server. I am using GraniteDS to connect between the application server and the client. The client side is flash-based.
Granite DS requires the use of the APR library (apache native library), so I am loading it. I see in the JBoss logs that it says it loaded the apache native library just fine (version 1.18, though I've also tried 1.20).
The issue is that when I have it so the APR library loads successfully, then the Flash side of the application does not usually load. I'll have to hit refresh a bunch of times and eventually it will usually load, but normally I'll see either a black webpage that says "Done" or the loading progress bar never move. Only by repeatedly hitting refresh will the page load. It will load eventually by hitting refresh enough, but it is not consistent and this obviously will not work for our clients who have to clear their browser's cache every time.
This problem only exists on Solaris, our application works fine on Windows. We've tried multiple patch-levels of solaris, and have verified with the "ldd" command that the library that needs to be loaded has all its dependencies there.
We've verified it isn't our swf file's size by testing:
1) Our regular SWF (1660 kb).
2) A random large-ish SWF (950 kb).
3) A small SWF with one label component that says "Test" (277 kb).
All 3 were unable to load when JBoss was also loading the native library, and loaded just fine without it. We need the native library to load successfully for Granite to connect between the client and server though, so not loading it isn't an option (unless there's some way to use the NIO connector with JBoss, but it appears unsupported).... if there is a way to use the NIO connector then we shouldn't need the APR library.
Has anybody run into this before? Anybody have any ideas or recommendations?
Have you tried the jboss native libraries for Solaris ?
http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html