Auto reload client-side files in sails.js/node.js - node.js

How can I auto reload the client side files such as the .ejs and the javascript files?
I have tried using forever but it seems to only autoreload the models and controllers.I'm looking for a way to auto-reload the client side files.

For now, that can not be done. Only models, controllers, views and services files are reloaded. All other can be reloaded only manually.
https://www.npmjs.com/package/sails-hook-autoreload
Anyway I do not see the problem. Only configs and static files are not updated. That is done by Grunt at server startup. And you do not need to do it often, so you can manually restart server.

I managed to solved it.
auto reload doesn't work on production mode. Only on development

After lost some time trying do this with sails/grunt, i install the livereload browser plugin (http://livereload.com/extensions/) for .html, js and css and the package (https://www.npmjs.com/package/sails-hook-autoreload) for the models and controllers.
It has another way in the link follow:
Get livereload to work with Sails.js

Related

React plugin to write files to server in development mode

I am looking for a ready solution for the React development mode that allows modifying server-side files from the client-side scripts.
How it can work? For example, it is a small server script or an extension for create-react-app that can receive upload requests from the client-side script to modify source files.
I need to renew several source files (files2) automatically when other source files (files1) are modified. The client-side react script will process the js object taken from the custom webpack loader, that loads source files1, then I need to renew some source files2 that is using by another webpack loader.
This scheme will not be active in a production mode.
I know I can write my own nodejs based server that will communicate with my client script and modify files, but I am looking for existing solutions and furthermore, I'd like to use the same connection that React development server created to avoid CORS headaches, etc.
Do you know something good about this?

Node JS : Editing .hbs files not reflecting changes in Browser View

I am new to Node and working on an application using NodeJS, Express, MySql and Sequelize. Its an application that performs CRUD operations.
For learning Purpose, I am working in a github project.
I came across .hbs file in Views folder.
I tried to edit the Heading name in this file, but still my changes are not reflecting in Browser View.
Is there anything I am missing? Even after restarting server, my changes are not visible.
Reason :
Handlebars (hbs) is a server side view template. It needs to be compiled on the server when any changes are made to it. It is not a .html for which you don't need to restart the node server to see the changes.
Solution :
Restart the node app to reflect any changes or better use nodemon.
Cheers.
P.S : Mark the answer as accepted if it solves your problem.

NodeJS disable cache

I now learning NodeJS and I want to use Mustache-express as the template engine (I want to use it instead of Pug, because I used it before on FrontEnd and I think it's a really smart and easy template system). I use nodemon to run the NodeJS server and it's work correctly, it restart every time when I change any file, except the views. When I change anything in the view files, I don't seem it in the requests' responses, only when I restart the NodeJS server. What can I do with that?
I already turned out the cache with the following code:
app.disable('etag');
Run nodemon with the command nodemon -e js,html (if the extension of your views is not html, then replace it)

Dojo javascript files/paths are not instantly showing in browser using Sails.js

I have a lot of files in my assets/js directory. At first I thought I was somehow losing the ability to see/serve files from sails. But after I let sails run for a little while, it seems sails found my files in the assets/js directory and I was able to run my intern tests. I'm assuming there is some type of behind the scenes cache going on that must run before I can successfully make a request. Is this the reason, and if so, how can I disable it for a more instant access to my files?
Sails.js needs to do several things before lifting the server, you can try sails lift --verbose to see what's happening.
Also, if you dont mind, take a look the .js files under tasks/config/, Sails.js uses them to link/copy/build assets before starting.

Node.js on Heroku: use middleware on development, but static assets on production?

Some middle languages, such as Stylus, provides two ways to be compiled: through connect middleware or through CLI tool. The later can generate static compiled assets(i.e. .css files).
So I want to use middleware on development mode but static assets on production. I know that I can use app.configure('developmen'...) to ask express (not) to use some middlewares on development mode.
On an IaaS enviroment, like Amazon EC2, I can run a simple shell script to automatically re-compile all my assets. But how about PaaS, specifically Heroku? How can I tell it where my .styl are and where the .css should be generated?
You may want to take a look at https://github.com/adunkman/connect-assets . It caches any built javascript or css files (it has stylus built-in support for stylus) if you pass it build:true .
You can ignore snockets (sprockets-like javascript include system) if you're not interested, although I enjoy using it. #= require_tree app and you include all the js files in that directory. And in development, you get separate script includes for easy debugging.
The biggest downside of serving directly with connect-assets on Heroku is that you need to git push to Heroku for every update to client code, which automatically triggers a restart. I ended up manually building my assets (with stylus and snockets), then uploading to S3. If you don't need to update the client code often, it's not that big of a problem though.
You can take a look at express-cdn, which will upload your assets to S3 on server start.
What I ended up doing was signing up at CloudFlare, and found that it wasn't as fast as using CloudFront, but it was very easy to setup and it works better than serving asset files from my dyno.

Resources