I am running Rails 3.2 in the development environment. Somehow, I have gotten into a situation where any change to code while debugging hangs up in the asset pipeline while trying to deliver the new page. By hangs, I means it takes a very very long time which usually causes a timeout somewhere. At present I'm debugging some javascript so all of the assets are unchanged except for one JS file. There are no error messages I can see anywhere. When I use Chrome to look at network activity it is always hung on a pending delivery of application.js, which is where the js manifest lives.
The work around seems to be:
clear the cookies and cache on the browser
restart the app server
go to localhost:3000 to re-sign-in.
I have to do this every time I change a line of code in JS.
Clearly I am doing something wrong and this used to work fine. No new gems, so new workflow. I did not accidentally precompile assets to my knowledge.
Why would the pipeline hang delivering my custom JS (not bootstrap or angular)? Why in such a way that the work around works?
I notice several unresolved questions about this so if anyone has a clue it might help a few of us.
I just had the same experience. Deleting Rails' tmp folder seems to have solved it for now.
Related
I have been using webpack hot reload in development and it is awesome. It saves me a lot of time. I have been searching over the web today to get a good grasp of how it actually works and have not found any good explanation about the internal working of it. So, I am asking here to get a good understanding of how it actually works.
I have come a bit in my mini hot reload project. For now, I have set up a node server and a simple client side Javascript code. The client is connected to the server via websocket and the server fires change events to client based on fs.watch function from node.jsthat watched my code folder for every file change.
I am stuck at how I can patch the update I recieve from server in client code. Right now, I have just index.js file in index.html. So I am wondering how bundling tools like webpack achieves hot reload, specifically how they patch the update.
I've read from webpack docs that they have a thin hrm runtime in client code that update the patch, but I could not seem to find any detailed info on how they achieve this feat. Do they open the client index.js file using FileReader, read the file and write(?) back? Again, I do not have a clear understanding of how this works. So, if you guys could give me some direction, I could dig deeper into it.
So my question is, how do they patch(insert) the new code into the already existing client code which resides in index.js?
I have spent a lot of time working on a webpage and have been very lazy about committing things to Git. Today, I attempted to push everything up to my repo, but I think I may have caused a disaster. I am very new to Git and basically just use it for its most basic functions.
I was unable to push anything and the console recommended using a pull request, after doing that and attempting to push again, I began to get a bunch of merge conflicts with my gemfile and gemfile.lock. I tried fixing this issue as well but then I started seeing random <<<<<<HEAD throughout my files (including routes as well as my javascript).
Now when I try to load my localhost page, I seem to have all my content, but my css file will not load resulting in a very ugly page. When I use chrome devtools and try to look at the sources, the application.css.scss is blank, when mine have 1000+ lines of code (and is viewable in the app\assets\stylesheets folder.
Has anyone had something like this happen / know how to remedy the amount of damage I might've done in 15 min. Anything will help as I do not know how to proceed.
you'll want to try doing a git reset --hard to reset your local repo to the state it was at before you ran git pull.
see this answer for reference:
https://stackoverflow.com/a/1223385/3880374
also, in case you're curious about those "random" <<<<<<HEAD strings throughout your files, those are actually added by Git. Per their docs:
Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts
Github also has a helpful guide to resolving these conflicts via the command line.
I have a new project with the following components in use:
Node.js (v0.10.37)
Express micro framework
Jade templating engine
Angular.js (latest)
Material design library (material.angularjs.org)
Jquery
I have an issue when I do browser reload (hitting the browser refresh button). I am not using any of the Angular.js routing capabilities. I am using the Express router and I have a route for every page.
When I try to refresh, a page build with this components, sometimes (1 of 20 reloads) the AngularJS just doesn't run without any console errors.
The issue is more common when I navigate between routes like:
I am on localhost:3000/index and I go in localhost:3000/about
In this case is more likely to occur this issue.
EDIT: I am not using any of the AngularJS routing capabilities.
EDIT: I also tested the DOMContentLoaded wrapping solution.
EDIT: I attached a plunker but the issue doesn't reproduce. I think it has something to do with the server too. The plunker is really close to reality.
ng-app="StarterApp"
See the plunker :)
EDIT: http://plnkr.co/edit/Vi1AQxNxJTDBf4B1ZEhr?p=preview
EDIT: If you encount the error on plunker please tell me.
EDIT: I also tried to activate: $locationProvider.html5Mode(true);
EDIT: I also found that this occurs when the server and computer (running on localhost) is really stressed. (82% RAM - 1 CPU core at 99%)
I also tracked the requests and I found that the files are loaded correctly on main requests but the requests done in Angular (Ajax requests) doesn't fire.
I also installed some Chrome AngularJS debugging plugin and it doesn't run either when this occurs.
This happens on all my pages sometimes, so I don't think that some code will be useful.
To fix this I reload again and sometimes I reload 2 times to fire up the Angular.JS.
This are the following cases:
When it is working
The interface
The console
When it is not working
The interface
The console
It really annoys me. I will continue investigating this issue but I will really appreciate any help.
Evrika!
I found the problem. Thank you all for support.
It was a problem about angular.js debugging chrome/firefox extensions.
The Ng-Inspector loads on every load a script ng-inspector.js and in this script it is a controller that deals with $state service and declare how to load the user modules in order to push debugging data into the plugin.
Somehow this loading configuration messes with my loading configuration.
The code was well-written but I didn't thought about this.
So if you encount this problem make sure that your debugging plugins (ng-inspector and angular batarang) don't interact with your business logic inside your project.
I made some stress testing to make sure that this issue doesn't occur anymore.
Server load
Now everythink is ok.
I have coffee script in my rails project that is easy enough to turn into javascript. The js files are hosted locally in my dev environment in which they work as expected.
When I push to Heroku though, certain behaviour is not occurring (though plenty of stuff within the same file is working as expected). The console is not giving me any errors and the script I'm worried about is now merged with a bunch of other js files and uglified.
How do I find out what the problem is?
When building, or "on the fly" (perhaps with caching) when the users request pages.
And what are the dis/advantages of each.
When the site moves from dev to the live server.
I always have an uncompressed version of the JS on the dev server and a minimized version on the live server.
The advantage of that is when developing i can run into JS trouble and fix it very simply, but i need to run each changed script through a minimizer, but for me its not that much.
When building or deploying to a stage environment is a good time to compress javascript. That way you will have a chance to test it in the stage environment and catch any errors that could occur.
Occasionally, there are errors that do come up when compressing. You may want to include a command-line version of jslint that runs before compressing, to make sure that the js passes. That will minimize, but not eliminate, all compression errors.
I'd imagine that on-the-fly would be an unnesessary unless you were adding dynamic data to the JavaScript (in which case there are better ways around it). IT's just a needless expenditure that will only slow down the page load.
Personally, I'd do so when deploying/building the app, it's a one-time thing really.
I'd say you have the js files as you'd code them in source control, when you kick off an automated build that's when, as part of your build script, it runs all the javascript files through a compressor. This way when you deploy it to a test / staging environment you've got the latest script but also compressed for performance testing and as they would be once they go to production.
I agree that on-the-fly is probably not really necessary (and eats up some cpu cycles) if the JS does not change.
There might be some middleware involved though which can check if the JS has changed and compress it only if requested (and maybe even group various JS files into one resulting one).
A good thing when deploying might also be to add some time stamp or random string as parameter to the JS link (e.g. .../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs). That way when the JS changes you use a different string and there will be no caching problems because it's a new URL. Same for CSS.