When creating an app with react-native init I have hot reloading and live reloading automatically configured and can enable them from the developer tools. I understand that Live Reload will reload an app, whereas Hot Reload will just reload changed files and maintain your current state in the development environment.
From these descriptions I've read it sounds like Hot Reloading is always preferable to Live Reloading and I should never even bother to enable Live Reload. I'm curious to know if there is any time where Live Reload is more advantageous? Or is it just some sort of built in fallback in case Hot Reload won't work with your other dependencies?
When it's about UI things hot reload looks enough. There some UI change that breaks hot reload. For example removing flex:1 for some components in android. I think for developing UI part it's okay to just use the hot reload. But when the logic comes, it's a different story. For example testing your fetch which lives is in the componentDidMount. You have to reload the app. Or you are debugging the app. Making some changes want to see the changes in the debugger.
Related
i'm having trouble developing with Nuxt3, the problem is that sometimes edits in the code are not visible, it seems that Nitro caches something and I need to restart the server in order to see the updates. The most effective example is when I console.log something, then i remove the line, but the log still get printed after I reload the page. Any tips?
I used xcrun safari-web-extension-converter to convert my chrome extension to safari extension but it built with this warning
Warning: Persistent background pages are not supported on iOS and iPadOS. You will need to make changes to support a non-persistent background page.
Also when using it on safari, it is showing these errors:
Extension errors in safari
How can I debug the errors in the extension? I'm not sure about the error but the persistent page warning seems to be a good place to start with. While searching for it in google, all I got is results for non-persistent background pages.
Do let me know if any more information is required.
PS:
The extension option in the "develop" menu of safari is also disabled due to service_worker failed to load error.
From WWDC21-10104:
The background page is a web page that the browser loads to run your
extension's background script. And this page allows your extension to
handle events sent by the browser or other parts of your extension.
But keeping this page loaded has a performance cost. It can use memory
and power as if you were keeping one more tab open and running for
every enabled extension. Keeping all these pages loaded all the time
can be pretty wasteful. But you can make a background page
non-persistent, which means the browser will only load it when your
extension actually needs to do work, and the browser can later unload
that page when it's been idle for some time. That way, the performance
cost is only paid while your extension is doing something useful. This
is important because background pages must be non-persistent on iOS,
where system memory and battery life are especially at a premium. The
web extension templates in Xcode already come with a non-persistent
background page, so they're ready to run on iOS. But if you have an
existing extension that uses a persistent background page like Sea
Creator did, you'll need to change it to be non-persistent. And you
can do that by adding that "persistent:" False key in the background
section of your manifest.
So you can solve it by adding this to your manifest.json:
"background": {
"scripts": [ "background.js" ]
"persistent": false
}
I'm trying to build a Vue web app and a friend was using it when it froze. Refreshing the page or opening a new tab and going to the page didn't fix it, and it would just keep loading until chrome said the page was unresponsive.
I thought it might be a network issue on their side but it works fine on their phone. Then I thought maybe there was a localStorage or cookie corruption issue, but then it was still broken on a different browser(chrome & edge).
https://i.stack.imgur.com/CTLTs.png
https://i.stack.imgur.com/zbjdr.png
This site doesn't seem to show any HTML and upon reload, nothing pops up in the network tab.
https://i.stack.imgur.com/zjqrk.png
The site uses vue3, vuex, fullcalendar, fontawesome, lzutf8(compression algorithm package). It's hosted on netlify.
Honestly, I don't even know where to start debugging this since I can't reproduce the issue on my computer and it makes it worse than I don't physically have the laptop in front of me. Here are some issues I think it may be:
There is some corrupt data between chrome and edge that's causing the site to freeze
I'm using a compression algorithm package to compress the vue store into a copy/pastable string. It's possible this is causing the site to slow when vuex tries to load the getter for the compressed store, but if the localstorage is empty all it has to compress is empty arrays so I don't see how compression would cause an issue.
A firewall on the device could be blocking the website
Maybe there's a chance Netlify could be blocking the site?
Potentially there's some issue with vue or vuex that I don't know about?
Here's the github repo: https://github.com/ZombiMigz/cpp-scheduler-webapp
and the website is deployed here: https://cppscheduler.com/
Any help or ideas would be greatly appreciated
I've built multiple sites with Nuxt SSR, but never touched the static part.
As far as I know, upon build-time, Nuxt automatically executes all API calls and caches them.
If I want to make a blog with a static Nuxt site, how would I update the content? Is it only possible when I rebuild the app?
Seems unnecessary to rebuild everything every time I add a new blog post. With SSR I just reload the page.
Also wanted to note that I have a Strapi.js backend running on a VPS and I usually make changes weekly. Nuxt's docs state that I need to push my changes to the main repo branch but there's no changes on the frontend.
Does this also mean that the headless cms should be local only?
The whole point of having a static build is to have all the generated files with no additional server Node.js server needed. It reduces heavily the costs, removes a point of failure, discard any notion of server charge (amount of users at the same time on your app) and probably some other advantages yeah.
Downside, you indeed need to actually yarn generate the whole app again if it's something that was added/changed in the codebase. Usually it's pretty fast and there are also incremental builds if I do remember properly (you will not regenerate all the 99 old blog posts but only the 100th, the new one).
Headless CMS like Strapi usually work with a webhook: you add a new CMS article or alike, Strapi will notify your JAMstack platform to rebuild your app. Even if no front-end code was changed, you can force to build it with the new data coming from the headless CMS' API.
The problem is that site view in cms differs from live site itself.
In cms edit mode I've deleted component from container inside page, saved, then published changes. Publish done successfully without any errors and site view in cms looks correctly, i.e. without that component that was removed. But this component still appears in live site.
I can easily fix this problem by removing this component in console. In cms console it can be seen that preview and working configuration differs.
But why this type of desynchronization happens? And what can I do to prevent this kind of problems?
This type of desynchronization happens rarely, but this problem may be very critical in production.
I am using Hippo CMS 10.1.0 Community Edition
If Your configuraton have been resynchronized, good way is to remove whole preview node. This node will be reconstructed from Your live node when You enter in CMS and turn on edit Mode.