I am currently working on a project that is in SPA mode of Nuxt and I want to add a package called nuxt-password-protect. This is for security reasons when opening any environment such as dev and staging. I want to provide a password for every access to my staging or dev links. But I am quite confused if it is really necessary to change the mode to SSR/universal? I already changed my mode and it seems working when I also installed the package. Can someone expound some knowledge with this? I am new to nuxt and Vue.
Related
Basically what I have is my frontend (Vue) and my backend (Node.js and etc.). By following a guide, I've built the frontend for production using npm run build. I got a bunch of files in a build folder I setup within a previous step. These files were then moved to a folder in the backend. It works, but it's more a demo than anything else, and the frontend and backend will have to be modified more as I continue.
I'm just wondering if and when I edit the fronted more (let's say, when I add a new page) am I supposed to go through this process again? So I'll modify the front end folder, build that, move files, etc.
Thanks.
Yes, definitely.
If we are in a development environment, we use npm run dev or yarn run which upholds the development environment running and updates the browser whenever any modifications inside the code happen. We don't use any final build in the development environment because we make code modifications so repeatedly that it would be a sore process to make a build after every modification and check the results using that build.
But, the production is distinct from the development environment. We deploy the only code which is bug-free, entirely working, and ready for users to use. Deploying to production means all changes have been made, and the final code is ready to be deployed. So, we make a final production build and deploy it to our server.
So, don't panic to deploy to production every time you make a small change in the code. First, complete your all changes, and test the changes in the development environment, if everything is working correctly then only create a final production build, and deploy it to the server.**
I hope this helps.
I have vue project which published on Digital Ocean. The main problem is when i make some changes on FileZilla it is not affect on website. How can i solve this issue?
This is not an issue per-se. This is just the way how modern web development works. Vue.js (but also Nuxt) is using a bundler right now (Webpack, Vite are the most common), hence to go to production it needs to be bundled each time you push something to it.
If you upload something via FTP or SSH and edit some source code, a bundle step will be required in order to get any changes on the actual webapp.
Backend languages may not need that, for example you could SSH into a server and change some .php file, if you F5 the page it will be updated in real time. But this is not how frontend JS code works, it needs to be optimised.
Another thing, sending code via SSH/FTP is not really a good workflow because it is not easily trackable, no version-controlled, will not trigger any build flags in case of an error etc...
The best approach is to have a git repo + some build step included in some CI.
A common platform for it is Netlify, you connect a Github repo, you tell which command to use to build the project and each time you push some code, it may do some checks/tests/optimizations/etc... via Github Actions before being released automatically to production (updated on your webapp).
This workflow have a lot of benefits as one may tell but is also de-facto, the official/regular approach for modern Web development on the frontend.
I am unable to see the navigator.virtualKeyboard API present in create-react-app production build, but it is present in local development. What settings do I need to tweak to enable it in production build?
Please head to:
https://w3c.github.io/virtual-keyboard/
I´m not a React User, but I think that´s not your problem here, but this:
maybe your dev/prod systems have different setup.
I am heading toward my first Nuxt deployment, of a large internal application. And I’d like to support IE 11, at least for a while. But when I generate the deployment files and attempt to access a staging site with IE, I immediately receive a syntax error from one of the generated js files.
Here’s a start at specifics:
Vue 2.6.12
Nuxt 2.14.6
Vuetify 2.3.2
Nuxt plugins for axios, auth, and a few other plugins.
The application is deployed to IIS, using nuxt generate and copying the dist directory to the server. I have tried using the generate command with and without the modern -m flag. There is no possibility of deploying other than through IIS (client specification), and I’d prefer not to have to run Node there, since the static deployment should work.
I am developing on a Mac and thus have no practical way to run and access the dev version by IE.
The application works properly on modern browsers, but throws an immediate syntax error in IE.
My understanding was that an IE-compatible version would be transpiled during the generate process, but evidently I’ve missed something.
As I say, this is my first Vue/Nuxt deployment, so any advice would be appreciated. I’ll be happy to provide any further specifics.
Thanks in advance for any suggestions on what/how to troubleshoot this.
Please follow these steps
Check if the syntax error is caused due to any dependency. I ran into syntax error when using vue-calendar plugin. This plugin has problem with IE11
Try adding pollyfill.io into your application. Inside your nuxt.config.js try adding inside head
script: [{ src: 'https://cdn.polyfill.io/v2/polyfill.min.js' }]
If adding to nuxt.config.js doesn't work , try using the code into your app.html file
My team and I have a medium-large web application which uses Vue 1 and Vue-router 0.7.
Last days I was thinking about how I can migrate my project from Vue 1.x to Vue 2. In my opinion there are two possible methods:
Stop my web application development and migrate all the platform in
a few weeks.
Do an incremental migration. Some componentes will use Vue 1 and
other components will use Vue 2.
CONSTRAINTS of each option
I can't stop my web aplication because It is stable in a production
environment and I have to add features and fix issues.
I did satisfactory tests with components using Vue 1 and Vue 2. The
problem is that It is not possible to use same Vue-router version,
so I can't share routes and navigate between components...
The best option for my web application could be doing an incremental migration but...could It be possible?
Thank you for everything!
I think it is possible.
The key thing is we have to make sure Vue 2.x and Vue 1.x are able to pass data to each other, and the reactivity should work to avoid complicated blocks of code.
I've made an example here: https://trandinhkhang.github.io
About Vue router, I think we can watch for a property and then do a router.push("some-url") in both Vue Router Vue 1 and Vue Router Vue 2 to navigate. Etc.
My company have the same troubles as yours and migrating a monolith into new platform is hard and seems impossible. Lolz. Incremental migration still the best option here.
VueJS 1.x and 2.x is totally different. 2.0 is written from scratch. VueJS have an awesome migration helper which can be used and it will do lots of work for you.
Read the following migrating guide: https://v2.vuejs.org/v2/guide/migration.html
I am not sure who gig your app is but it should not take more than 2 days for a medium size application.
Here are few points from their official doc:
Where should I start in a migration?
Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.
After that, browse through the table of contents for this page in the sidebar. If you see a topic you may be affected by, but the migration helper didn’t catch, check it out.
If you have any tests, run them and see what still fails. If you don’t have tests, just open the app in your browser and keep an eye out for warnings or errors as you navigate around.
By now, your app should be fully migrated. If you’re still hungry for more though, you can read the rest of this page - or just dive into the new and improved guide from the beginning. Many parts will be skimmable, since you’re already familiar with the core concepts.
By the way, You should not upgrade the app incrementally, In my experience, it will be total mess.