Maximum recursive updates exceeded, only on iOS in a specific component - vue.js

I have a Vue3 app which is giving me multiple errors only when I mount a specific component within my generic modal component. On desktop across browsers I get zero errors and everything works as expected. On iOS (using desktop Safari connected locally to capture console logs) it shows the log below, along with a few other "Maximum recursive updates..." from other components (which have nothing to do with the modal or it's inner template).
I've checked every single component that is listed in the error below ("at~") and every other component that is used in that modal template (it's only one template that breaks) and NONE of them are using a mounted hook, so the "Unhandled exception during mounted hook" doesn't make any sense.
I know this is not much to go on, but has anyone else seen this recursive error happen only in certain components and only in iOS before?
In addition to the above, I've double checked all logic for any recursive issues and have found none. And, if there really were some, I would assume they would show up on desktop as well, not only on iOS.
Pretty stumped here, friends.

Related

React Native - console.log and network commands are not working

I've a strange problem in app I'm currently coding.
Here is the story of the app :
I've used React Native's ScrollView as a horizontal slider,
I display maximum 5~6 slides so I don't need to use FlatList for this.
Slides are actually records coming from the database so actually they are some dynamic components
and slider works as expected.
In every slide, there are also are some option buttons (Touchables) to send data to the server.
When the user presses a button app is opening a modal window to confirm and then sending some data to server.
Until now all is okay.
The Problem :
But in some slides of the slider I'm having a strange problem :
"console.log" commands and also network commands to send data to server is not working.
On the screen, I see Buttons(Touchables) are working and also the modal I've coded is also appearing & disappearing according to the state variables. But somehow console.log commands and also network commands are not even executed. Since I can't log anything it's also hard to understand the problem.
Is there anyone had a similar problem ?
Thanks
I've finally solved this problem, wanted to share my experience here.
In the app I was making post requests to the backend with Axios,
but I wasn't interested in the result of this post requests,
they were just log records so the result of backend calls weren't important.
So I didn't use any "await" command or didn't code anything like Promise.then / catch,
just posted with Axios and scrolled to another slide in my app without waiting for the backend.
After the 8th Axios post, app started not to work.
It seems like working .. touchable effects , modals even navigation works
but nothing else was working. Event console.log commands weren't working.
It's an interesting behavior of React Native , but I've understood the situation after reading the blog below :
https://medium.com/#rotemmiz/react-native-internals-a-wider-picture-part-1-messagequeue-js-thread-7894a7cba868#
Basic reason was that in the backend (NodeJS) I didn't return any response,
there wasn't any command like res.send("success") .. so frontend React Native app was waiting for the response.. event if I didn't use any await or Promise it was still trying to get the response and after the 7-8 call it was blocking the main thread.
If there is a way to configure Axios not to wait for the backend to answer for the post request, please write here.

Prevent my Elm app from crashing when a 3rd party changes the DOM

I have an Elm app. A while ago I realized that my app was crashing locally when I used FontAwesome icons. I came to understand that it happened because I chose SVG icons and therefore FontAwesome was modifying the DOM. That conflicted with Elm's VDOM mechanism.
This was easy to fix--I migrated to the CSS version of FontAwesome that uses pseudo elements. Recently some users complained that the app in production freezes and they showed screenshots of states that were not matching the log data I had. It took a while until I realized that all these users had Google Translate automatically translated the page for them. Google Translate clearly alters the DOM, so I'm not surprised that it made Elm crash.
How can I prevent my Elm app from crashing? Is there a way to be notified if a 3rd party changes the DOM? So that I could even notify the user that they have an extension that interferes with the app.
I had the same problem as you and solved it by migrating to the Elm-FontAwesome library. Basically all you have to do is replace this syntax:
i [ Svga.class "fas fa-check" ] []
with this one:
Icon.viewIcon Icon.check
You can have a look to the example project for more details: https://github.com/Lattyware/elm-fontawesome-example
Have a look here - How we made Elm and Google Translate work together.
Their approach is to hijack the Elm replaceData method that is called by Elm during dom updates using the function below. You would run this just before giving Elm control of the dom.
HTMLFontElement.prototype.replaceData =
function replaceData(_0, _1, string) {
this.parentNode.replaceChild(
document.createTextNode(string),
this
);
};
Apparently, "Google Translate replaces every text node in the DOM with a tag containing at least one more tag – one for each sentence". For example:
<span>Insurello. Rätt ersättning till alla</span>
is translated into
<span><font><font>Insurello. </font><font>The right compensation for everyone</font></font></span>
This method avoids attempting to edit the span and instead replace it with a new one. Once the node is added, Google Translate will translate that text.
I don't know about preventing the crashes, but I think you should be able to register changes to the DOM with the current mutation observer API.
Before that were several deprecated mutation events like DOMSubtreeModified that could also help, but well they are deprecated.
This problem is very closely linked to that of Google Maps or Google Places Autocomplete in Elm. The solution I've used in the past is to provide a childless div with an id I can point to from JavaScript.
Because the div is childless, Elm does not look under the hood to check whether it has changed internally.
Check out this blog post or google "maps in elm" for instructions on how to do this
-- EDIT --
Ive read the question better and this will probably not work for Google translate issues as it changes all text in the entire DOM. Ill leave it here incase the question brings otger people who have more regular problems caused when a 3rd party changes the DOM

Does Electron have a standard way of killing a useless renderer process?

My app creates a window with a local page that requires node integration to be enabled.
After I click a button on this page, I am navigated to a third party page.
Because I want node to be disabled in this third party page, and I can't toggle node integration in a BrowserWindow, I load this third party page in a sandboxed BrowserView that is embedded inside of the window and is stretched to fit the entire screen.
Now doing this navigates the embedded view, but the BrowserWindow is stuck pointing to the old local page that is no longer relevant.
To prevent this extra page from sitting around in the background, I navigate my BrowserWindow to "about:blank" to effectively clear it out and make room for the BrowserView.
I am realizing now that while this "clears" out the old page, it keeps the renderer process that's associated with it alive. From here:
Chromium creates a renderer process for each instance of a site the user visits
And understandably, navigating to "about:blank" doesn't signal to Electron that it should kill the other process.
I want to get rid of this renderer process, so it doesn't sit around unnecessarily and use CPU and memory when I interact with the window.
Two things that have worked:
I removed the extra navigation to "about:blank" since we're now killing the process and:
1) When my button in my renderer sends a message to the main process telling it to create a BrowserView and navigate to the new site, I do a process.exit();. I guess a part of me is nervous about the process exit interfering with the message that gets queued up for main, though it seems to work fine.
2) Instead of killing the process from the renderer, I created and navigated my BrowserView and then ran a little browserWindow.webContents.executeJavascript("process.exit()");. I find this uglier, though it does mitigate by concern above in #1.
There isn't a webcontents.destroy() type of method, and I don't know of a way to signal to Electron that it needs to destroy this unnecessary process.
I suppose I might have a pretty unique case, but is there a nicer way (or more standard way) of handling this than explicitly doing a process.exit()?
There is now a WebContents::forcefullyCrashRenderer() API that accomplishes this (introduced by this PR):
Forcefully terminates the renderer process that is currently hosting this webContents. This will cause the render-process-gone event to be emitted with the reason=killed || reason=crashed. Please note that some webContents share renderer processes and therefore calling this method may also crash the host process for other webContents as well.
As of now (July 2021, Electron v13) - there's also an undocumented webContents.destroy().
https://github.com/electron/electron/issues/10096
As the documentation mentions, some webContents share renderer processes and if you use webContents.forcefullyCrashRenderer() you may terminate them as well.
I'm not sure about how webContents.destroy() handles it, but from the name it seems to be more narrow in scope. I would assume that it kills the renderer if webContents is the only webContents attached to it (I tested this) and spares the renderer if other webContents is using it (needs confirmation).

VS Code stops letting me collapse code and navigate to definition when working in Vue.js

I've been having a really weird issue with VS Code. After using it for an undetermined amount of time, I'm unable to collapse code and navigate to definition. The arrow indicators in the left margin for collapsing code disappear and I can't seem to get them to come back. Closing the file doesn't work, and restarting the app doesn't work either. The only thing that works is a complete system restart. The same thing happens with ctrl+clicking a class name expecting it to navigate to definition but it doesn't.
I thought at first it was probably an extension I installed so I uninstalled all my extensions, restarted the app and now the collapse icons don't show up at all. I'm working in VueJS and think it might have something to do with *.vue extensions but I'm not sure.
You need Vetur for pretty much any functionality in *.vue files, and Vue Peek for Ctrl+Clicking paths

Using Frames or changing visibility

I'm new to UWP (windows 10), working on an app for windows phone, I wanted to know what is the difference between:
Using multiple frames and navigate from one to other.
Using a single xaml with no frames but with multiple grids (or other patterns), and instead of navigate- just change visibility so only the desired grid will be visible.
which option is better? and why?
The system keeps track of the Page you are currently on. So even when your App exists and even if it's removed from memory the OS can tell the App to reopen on that page.
Similarily when your App provides other Apps with the capability of calling into it to open certain file types of to perform certain actions (e.g. start navigation, etc.) pages will be used.
Lastly if you put everything on a single page and just manipulate visibility this will increase memory consumption of your App (as everything needs to be loaded even if it's not visible) and it also might increase load times.
Of course how much that impacts you is up to the type of App you are building. In general however I'd advice you to start building using separate pages in case your App grows. Also you get a lot of stuff out of the box if you do so (e.g. animated transitions, etc.)