I'm using vuex in a Vuejs app. The purpose of the application is to connect to the server with WebSocket and then process the incoming data and write it to the Vuex store (incoming data is around 70-80kb on average and data refresh every 15 seconds). I also render the data written to the Vuex store in components.
Since my application is an information screen, it is designed to run 24/7. However, I am of the opinion that there is a memory leak as a result of long-term work. (After 4-5 days, Chrome prints the Aw Snap! error and the device's memory usage is constantly increasing.) Unfortunately, this leak continues even though I have made many adjustments.
I'm clearing references in methods like beforeDestroy. However, I suspect that there is a leak on the Vuex side as a result of the continuous updating of the data.
The application flow works like this:
ws.onMessage -> data send to store with store.dispatch() -> trigger components after vuex data change -> re-render components
I'm curious about your suggestions and recommendations.
Thanks
Related
I want to pause all dispatched thunks when I am offline and resume when I'm back online. Is createListenerMiddleware a good option for this?
I could create like a seperate redux slice to save the dispatched actions and just redispatch them, but this will lead to existing thunks returning a rejected Promise and throwing errors where called. I want the consumers to just not resolve the promise until internet is back again.
Would you use createListenerMiddleware for this or how can I pause redux thunk actions until online event triggers. I guess I cannot intercept thunks in normal middleware, right?
I tried also different libraries for that but I could not get any of them working because not maintained / broken types / etc.
No, the listener middleware is intentionally for "listening". It doesn't have the ability to stop or pause actions, and it runs after an action has already reached the reducers.
You may want to look at https://redux-offline.github.io/redux-offline/ instead.
There are also a number of Redux middleware for various forms of pausing, throttling, and similar behavior listed at https://github.com/markerikson/redux-ecosystem-links/blob/master/middleware-async.md#timeouts-and-delays . However, most of those were collected prior to 2018, and most likely few of them are written in TS. Still, some of those may give you ideas or code you can paste into your project for writing your own custom middleware.
The app I'm currently working on is supposed to get "live" data through a WebSocket after getting the correct WebSocket address (access token), however I am not sure how can I run it in the "background" - as in, maintain the connection and get data after changing the components currently shown on the screen, since I'd like to be able to move to different parts of the app without losing the data that is sent in the meantime.
How can I run the WebSocket in the background, and have the received data saved for use so that the component that depends on it is still able to access the data that was sent while it was not active?
I've thought about having the WebSocket save the events it receives directly to a Redux store, however I'm not sure what would be the correct way to set this up so that it runs all the time, independent of navigation between screens.
I have read a bunch of resources online but didn't see any similar use case. I need to send data from native (Android) to JS continuously, with the data being small sized string.
Would this (from RN tutorial)
reactContext.getJSModule(DeviceEventManagerModule.RCTDeviceEventEmitter::class.java).emit(eventName, data)
be the best way to do it? What if we need the message to be sent very frequently? Like every 100ms? Is there any other way to do it with better performance? How frequent can it go?
Thank you!
In react-native your javascript app is running on a different thread than you native application. I don't thinks there is a better way for sending data between the two threads than EventEmitter.
In the source code of libraries sending data frequently, EventEmitter is always used (example: react-native-sensors).
My app uses iCloud (key-value store) to sync an unique id between multiple devices. This works accept at the point were it really has to work, at the first launch of the app. It looks like the device isn't yet familiar with the values from iCloud at first launch, only after the app is installed and has been running for a while.
I check for the iCloud value in the viewDidLoad function on main view of the app.
So, my questions:
Is this the expected behavior?
If yes, is there another solution?
Could it be the case this is only a problem when running from Xcode, not the shipping version? If so, how to test?
Thanks!
Jasper
I had a similar issue where the NSUbiquitousKeyValueStoreDidChangeExternallyNotification wasn't triggering on the first launch after install, no matter how long I waited. Setting an initial key in the NSUBiquitousKeyValueStore seemed to solve this.
Immediately after adding the observer to the default store, I call:
[[NSUbiquitousKeyValueStore defaultStore] setString:#"testValue" forKey:#"testKey"];
[[NSUbiquitousKeyValueStore defaultStore] synchronize];
I use different keys (i.e. not testKey) for the actual data I want to sync.
When you first run an iCloud enabled App it has to pull all the data from Apple servers. The time it takes to do so depends on many things like what kind of network you're currently on (Edge, 3G, GPRS, WLAN). It also depends on how much traffic the iCloud server currently has to handle so the request to the iCloud server may take a few more seconds, no matter what type of network connectivity you have.
To sum it up: Yes, it sounds absolutely normal.
If running your App depends on those settings consider implementing a "Wait" or "Loading" view that stays on the screen as long as it takes for the App to perform a initial synch and load all needed data from the cloud. To not block the UI forever also implement a timeout for this view (if iCloud data not loaded within X seconds, dismiss the view and notify user).
You have no guarantee NSUbiquitousKeyValueStore would have finished its first synchronization as your app is launched for the first time. (In fact, on iOS 5, it's often starting to sync as you launch your app for the first time).
There is no way to know if the first initial sync has already happened, is ongoing or has finished. You can (in fact should) subscribe to NSUbiquitousKeyValueStoreDidChangeExternallyNotification. The trick is that if your store is empty on the iCloud server, you won't get any notification after the initial sync (since your local store is empty and the cloud store is empty as well, nothing really changed "externally" after the initial sync…)
Normally, you should not rely on the initial sync being done.
Be optimist at launch, even if your store is empty, push your values (e.g. your unique id) right away. If the initial sync happens concurrently or after and there is already some value on the server, your local values will be reset to the server values and you will get the NSUbiquitousKeyValueStoreDidChangeExternallyNotification notification with the NSUbiquitousKeyValueStoreInitialSyncChange reason.
Finally, if you really think knowing about the initial sync being completed or not, please file a bug to bugreport.apple.com and explain why you really need that.
Im working on a silverlight application where a user can create, edit, delete objects. The changes they make are placed in a queue which is processed every 4 minutes. When it is processed, the updates are sent over an async web method call to be saved in a sql database, one at a time. When the first update finishes, the next starts.
Im having a problem when a user makes a change and then exits the browser app before the 4 minute timer has expired. Currently the changes are getting lost.
Ive built on what the guy working on this before me has done, and explored the Dispose and Finalize methods, trying to start the update process when the factory is being shut down, but that isnt working due to the async nature of the web service calls. I get errors saying needed objects have already been disposed of.
Im looking for a way to save the data in the updatequeue using a webmethod when the user tries to close or refresh the webpage. Im not expecting the queue to be packed full with updates. This is an application that would usually be run for several hours at a time.
You can use Javascript to stop the user leaving the page. StackOverflow does it (try editing an answer and leaving the page). That works on browser close as well as page navigation. From Javascript you can also notify the Silverlight app to save any queued data (Silverlight support exposing methods to Javascript).
Q. Saving every 4 minutes is slightly odd behaviour for a Silverlight App. I am guessing it is only deigned to be run by one user at a time. What restricts you from saving more frequently?