I am writing a react native app and want to have a js file that listens to a server, fetches data from that server, and deploys changes to a redux store that updates my react components based off of the new data. I am curious, where is a proper place to instantiate this object that listens to the server? Currently, I am instantiating it in the top level component of my app like so...
App File
In ControlBoard, I initialize the object...
Control Board
and then the DataModel responds to the server and updates the application state through redux.
I am running into problems with this approach (ie sometimes ControlBoard is constructed multiple times). Is there a better way to accomplish this?
A a far better approach is to use socket.io to listen to any changes from your server then mapping it to your state and finally rendering it on whichever component you want.
There are many examples online to get you started, maybe you can look at this and this for a start
Related
My question is, what's the point of setting up Vuex for the server when the state will be overwritten when the client side hydration takes place?
I have some data (Helm env variables) that I want to store in the vuex store for later use.
These variables is only available to me on the server, so I started trying to add them to the store in my createApp script when running on the server.
The store state however is reset when the client side hydration kicks in, so no env variables left.
Google told me I should use like window.INITIAL_DATA to set the state again on the client:
store.replaceState(window.INITIAL_DATA)
But if have to use the window object to pass store data to the client, what's the point of using Vuex on the server at all?
Isn't it better to skip Vuex overhead on the server and just use Vuex on the client and populate it with INITIAL_DATA?
I'm probably missing something..
https://ssr.vuejs.org/guide/data.html#data-store
During SSR, we are essentially rendering a "snapshot" of our app. The asynchronous data from our components needs to be available before we mount the client side app - otherwise the client app would render using different state and the hydration would fail.
To address this, the fetched data needs to live outside the view components, in a dedicated data store, or a "state container". On the server, we can pre-fetch and fill data into the store while rendering. In addition, we will serialize and inline the state in the HTML after the app has finished rendering. The client-side store can directly pick up the inlined state before we mount the app.
Also to mention:
The data you access while SSR in any Component needs to come from somewhere if you want to share information across Components, this is what Vuex is there for.
My application requires the data in redux store to be persisted on app exit, I am looking for a proper way to do this.
I tried persisting data on componentWillUnmount of root component but it did not work. It looks like the process is killed before persistence is completed.
I also tried if AppState could be of any use. It does give information about the background/foreground status of the application, but it did not help either
Of course, I can update by persistence on every update of store, but I think there must be a better solution.
I'm new to React, I think the basics have sunk in but I'm stuck on something. We're going to re-build one of our old systems and I'd like to do it in React.
Our system is an internal CRM, each set of client data is about a Mb in size, so efficiency is one of our priorities. The logic is done on a separate API, used by lots of different systems, so 99% of this front end is CRUD only.
(I hope I'm explaining this Ok!)
So onto my question. If I make a small change to a part of the client data, say I add an 'Audit' to the client... there is a chance that LOTS of other data changes. Complex enough that I don't want to replicate the logic both front end & API side.
Would I need to have the API return the full Mb of data, to have the root level app re-render all it's components? Or is there a more efficient way of doing it? Should I be setting up each component to periodically ping the API to check for changes individually?
I'm just a little bit lost where to start tackling the idea of it. Any help is much appreciated!
First things first - React Components rerender when any props or state field was changed.
If you change smth on the client-side and changes should affect server-side which important for user, then you do should updated your app view. To make it more smooth you can use shouldComponentUpdate method of Component's lifecycle to prevent unnecessary re-renders.
If server-side updates are not important for user (some meta data...), then you may not update the state of you application, by that you prevent re-renders.
AsyncStorage is unable to retain data and I have run out of options to save
a set of objects and update them with new entries to the list. Please help
For Handling App's Data:
State - It handles component's internal data with not much complexity.
Props - It tosses data back and forth from parent component to children and vice verse.
Redux - It handles data efficiently using action-reducer-store architecture. Great for a complex app with a lot of user's data to handle.
For Data Persistance:
AsyncStorage - Simple API to save and manage data on device manually.
Redux Persist - Built over Redux to store all the Redux State data to device synchronously.
Hope this helps :)
Realm could be your solution: https://realm.io/docs/javascript/latest/index.html
Realm is a mobile database that runs directly inside phones, tablets or wearables. This project hosts the JavaScript versions of Realm.
Currently we only support React Native (both iOS & Android) and Node.js (on MacOS and Linux) but we are considering adding support for Cordova/PhoneGap/Ionic as well.
Features
Mobile-first: Realm is the first database built from the ground up to run directly inside phones, tablets and wearables.
Simple: Data is directly exposed as objects and queryable by code, removing the need for ORM's riddled with performance & maintenance issues.
Modern: Realm supports relationships, generics, and vectorization.
Fast: Realm is faster than even raw SQLite on common operations, while maintaining an extremely rich feature set.
Use case is a regularly updated display of vehicle tracking data retrieved through a REST call, onto a central office screen, with no user interaction.
There is no single answer for this, but some alternatives to consider:
add some JavaScript to your screen that uses the JS setTimeout() method or something similar to reload the page
for a smoother result but a lot more effort write the section of the screen that needs to auto-update as a Vue component and use the standard websocket interface to send data to the browser to update the data in the HTML; this is generally best done using the NotificationMessage interfaces and methods in the Moqui API where the JavaScript client registers on a topic and gets a notification along with any others registered (structure the topic ID as needed to differentiate different feeds) and have a scheduled service job feed the notification topic