Id like to run HMR in production, using it for seamless application updates. I cannot seem to find any docs or tutorials regarding how to do this.
My setup is currently "serverless", and statics are served from AWS S3. My first thought is i would create an "Update" server of some sort, wherby the HMR clients would poll for updates, and the magic would work.
My questions:
a) How do I run this in production (optimally)
b) For this to work the "Update" server will have to know of module changes, how?
I know the json file with the updates is what HMR relies on to know of the changes, will i have to push some sort of this file to the server?
Or, Do I have the server watch S3 files somehow, and recompile, in turn triggering updates.
A complete solution would be awesome, but also just some sudo logic as to how this could work would be great.
Read this two documents to understand how it works:
https://github.com/webpack/docs/wiki/hot-module-replacement-with-webpack
https://github.com/webpack/docs/wiki/hot-module-replacement
No idea to what you mean by "serverless"... How would you serve a website without a server? You will need at least webpack or a nodejs/express instance running somewhere
This will not be optimal. This feature is thought to be used for development. HMR will add listeners to the application for file changes and add code for replacing old modules with new ones. This adds overhead to your code. Optimal would be no hmr.
Related
I am a newbie with React.js and just for practice i made a simple counter web app.
But i noticed that the project is more than 120MB.
Is it possible? do i need to do something to shrink it?
120mb can he huge or nothing at all depending on where you get that number. Remember, a modern web app (such as one built with React) needs build tools and often a development server and more. Also, if you are using typescript it will in itself add a compiler that is up towards 40mb.
So if we look at the source directory you'll have your own code plus some build configuration (probably in a webpack configuration file) which totals a few kilobytes. But then we have the node_modules folder which contains all the dependencies for both your own code and the build tools. This isn't a problem and since this folder won't be sent to the client and you shouldn't even commit it to your SCM since it can be restored from your packages.json file.
I did a quick check of the folder size in node_modules in a new dotnet-react project (because that was what I had handy) and this is what I got.
So here we can see that typescript is by far the largest dependency eating up almost 25% of my project and there are still quite a few other large dependencies as well. But this is till just for
If we on other hand look at what is actually delivered to the client that should be a completely different matter. This is what actually matters since this will directly impact the performance of your application. A large app here will be both more code to download and more code to parse for the client.
This same app looks like this when running the project for development and checking network traffic in Chrome Inspector.
So here we can see three script files, but even in development mode only about 520kb is sent to the client even though my node_modules was about 180mb.
If we then go one step further and build this for production we get an even better result.
Now we are down to just about 270kb for the scripts which is just a fraction of the size of the project folder.
So to summarize:
The size is very well possible and kinda expected when working with a modern client side framework such as React (or Angular, Vue, Ember, etc).
The development folder will be large due to all the dependencies needed to build your project.
The final output will be way smaller but in the end depends on what dependencies you decide to use in your own code.
You don't have to do anything to shrink, just make sure that you don't commit node_modules to your SCM.
Also remember that all modern frameworks comes with an overhead to set everything up and making it easy to work with. This is most of the 260kb that my test app is. So if you make a simple counter the overhead will be extreme in comparison and not all projects need a framework such as React.
I am new to NuxtJS and JavaScript frameworks in particular. To host the files on an online server I need to generate static files. Even if I make a small change on one file I have to re-upload all the files again. Is that productive? Normally I can open the server and make changes to one file and upload it. But here I have to upload all files everytime.
Yes.
Some of the reasons why:
Your generated files are not supposed to be versioned, so any changes you make there, won't (shouldn't) be committed and pushed to git.
If you change the generated files and forget to change the actual code, the next time you generate the files again, those changes will be overwritten.
It's not going to be easy at all to make even small changes directly into the generated files.
You shouldn't be making changes straight into production. Also, the changes you make there shouldn't be reflected in your localhost, so you're going to have version conflicts pretty soon if you keep doing it like that.
There is, however, a way to make all of that easier. With continuous integration/continuous deployment, you can have it all set up so for every change committed/merged into a specific branch on you version control will be built and automatically pushed to your production server.
It seems to me like you are not familiar with version control (mainly git) nor continuous integration, so here's some topics on the matter:
GIT:
Learn git concepts, not commands
5 Free Courses to Learn Git and Github in Depth
Continuous Integration / Continuous Deployment
Understanding Continuous Integration
Explain Continuous Integration Like Im Five
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'm looking for a solution to have server settings in a config file of some sort separate from the JS app (which I could be running in dev or prod (built) mode) but allow for the server to replace the file with a new one at random point in time (when settings have changed) and allow the JS app to pick it up and refresh it's settings.
This is mainly for setting URLs to API endpoints.
My choice of JS framework is Angular 1 and 4 but answers geared generally towards various JS frameworks/libraries are applicable.
to have server settings in a config file of some sort separate from the JS app
If you are thinking about having your server settings exposed to the front you are gonna have a bad time ;)
I will assume that you think you will keep API URLs and maybe some config along with it in a separate file while you develop. Then I can advise two approaches:
1.) SIMPLE - Have a single JS file with a single object with all the necessary API URLs and settings in a tree like structure for organisational purposes. So you have a dev, a test and production property with everything in them. Once you load app 1st thing that should the app do is load the correct settings. This is fast and doesn't require any additional knowledge. Everywhere you had something configurable hard coded you replace it with a variable that derives from that file. This should suffice for simple applications.
2.) POWERFULL - For bigger applications with loads of different dependencies and more formal and professional approach do what most people do, use NodeJs, leverage Grunt or Gulp to help you version dependencies and write scripts for different builds. It requires you to install and learn to use new stuff but offers you way more power.
Even better combine this two approaches, link the external dependencies dynamically with the build and internal via including the correct JS file with all the API information.
You can also use other npm modules to assist you with your development like precompiling CSS, lint your code, rearrange and organise files by types into folders, auto-name files or folders.
Basically, MOST of the REPETITIVE tasks you do while developing can be automated this way. This truly shines on bigger projects when all this is handled by someone who is proficient and experienced with the 2nd approach, it can save months of repetitive tasks across the team.
You could use gulp (or even npm) as a task runner to do this kind of work. Maybe this article would help? https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/
The main point of a task runner is that you can set a specific variable ie prod or development, and the task runner can then switch out your config files with the present definitions for prod or dev config.
I am learning React and I'm running it using create-react-app, which allows me to edit text in a file named App.js and as I save any changes in that file, the webpage with the address http://localhost:3000/ in browser automatically updates without reloading. Normally, while making html/plain js files, i need to reload the page. So how does it dynamically update itself?
There is a concept of Hot Reloading. The idea behind hot reloading is to keep the app running and to inject new versions of the files that you edited at runtime. It leverages HMR and without reloading the page, replaces changed components in-place, preserving state. That means that, your change will be visible in about half a second; if it was a dialog, you wouldn't need to re-open it, your text inputs remain filled, etc. In short, it's a massive boon to iterative development where you spend much less time waiting for your app to reload. You can find more details here
The cli which you are using uses webpack to achieve this. Webpack is a module bundler it creates a bundle file from all your js/ts/jsx/tsx files which you embed into your index.html file.To achieve live reloading webpack uses webpack-dev-server(a small node.js express server).You can cofigure your webpack to watch for changes on your file and webpack will update your bundle file whenever your code is changed. You can learn more about how it does here.
All the configurations for webpack are written in webpack.config file.You can learn more about webpack here.You can also follow this link
This is actually not a standalone thing.
This happen because react use webpack dev server which reload package if you make any changes.
As if you want to do same , you need to setup a local server and always make editing in same server.
browserSync is also a option but you need to use nodejs then