I'm working on a small React application that uses Redux for state management.
The table below displays a dynamic list of objects, which are retrieved from the REST backend, which is implement in Java with Spring. Currently, I have to click a button in order to add the latest data delta (to the Redux store).
The table should update automatically in a performant way. I found a hacky workaround that recursively used Window's setTimeout method to periodically fetch data from the backend, but I did not like the solution.
What frameworks, tools, or approaches can I use for auto-updating that integrate well with React, Redux, React Redux, and Redux Thunk?
Since you're already using redux and react-redux, if an action is dispatched and the store's state is updated, the component should be rerendered with the new data.
When you call setTimeout to periodically fetch data, you're using a technique called polling.
To avoid the need to do polling, it's also up to the backend, whether you support WebSocket or GraphQL's subscription or using some kind of real-time datasource (e.g. Firebase)
May be CouchDB (or Couchbase (it's not the same) with PouchDB could help? I what try it in couple of days.
Seems they have Spring Data libraries
Using window.setInterval is better than window.setTimeout for this purpose. Other than fetching periodically data from your client, you could look into a websockets library such as socket.io although this will need configuration server-side.
If you are talking about auto-updating data reactively - when something in your database is updated - you need some kind of socket server for that. You can fire an event from your backend, and subscribe to it in your frontend, and then perform a query to fetch the data. I don't think using setInterval is a good idea for this type of stuff (in most cases).
Check out Pusher.
Related
We are in the process of slowly adding the graphql to our react project and replacing the existing redux integration. So I am trying to understand caching in the apollo and saw two things.
apollo-cache-inmemory (https://www.npmjs.com/package/apollo-cache-inmemory)
apollo-link-state (https://github.com/apollographql/apollo-link-state)
We have query to call list of apps on the home page and this list of apps will be using on some other page. So one option i tried is to call the list of apps query in the parent container and use the client.readQuery in the child pages, so that the call to the graphql server will be happened only in the container and in the other pages it will get called from the cache. But i saw some posts regarding the use of apollo-link-state in scenarios similar to this. So what is the best method to use here and when to use apollo-cache-inmemory and when to use apollo-link-state?
You shouldn't compare apollo-cache-inmemory directly to apollo-link-state. apollo-cache-inmemory is used to handle caching on Apollo Client, you don't have to do write any custom code for it to work (apart from just telling Apollo Client to use it). Any data that you fetch from api are cached automatically.
apollo-link-state however is meant for client-side caching, e.g. the NetworkStatus of the browser, or current active tab. States that usually not send back to a backend server.
So, you only need to consider whether you need client-side caching or not. In most cases that I saw, a project would eventually end up using both.
I am quite new to web programming. I've started developing a single-page web application using React.js with a Node server.
I've read the tutorial, played with boilerplates, and quickly I understood React would take care only of the view aspect. So I tried to put my data-processing functions with the export keyword in a JavaScript file so I could use them in my React components. But that way was pretty "dirty" and it didn't feel satisfying at all.
Then I looked for a way to effectively separate the model and the controller from the view, so that I could completely change the GUI with little effort, and thus allow the project to grow and multiple people to work on it at the same time.
I've came across this article explaining the Flux architecture, and I saw a major implementation to use with React.js was Redux.js. I was quite surprised that I didn't see it at first, and now I wonder how much frameworks one has to use when working with JavaScript and Web.
My question is simple : is Redux.js all I need to effectively separate data, treatments and GUI components ? Or did I miss something else ? Are there any other major architectures you would recommend ?
Many thanks,
Redux is generally used to contain all the data that your app needs. It acts like a store which can pass the required data to the components that actually needs the data. For example, if you need a particular data fetched from an ajax request to be distributed among two components, then redux is a perfect fit. Whether you need redux depends on how your app is structured. If you have an app with a large number of components and most of these require data from your server or api, I'd suggest you go with redux. Once you learn it, it's incredibly simple. And yes, redux is all you need to separate data from ui. To get a nicely formatted structure, put together all your ajax requests under a folder and export it so that you can call it from the ui component. And when you receive the data pass the payload to the redux store which will automatically pass it to all the components which are connected to that particular reducer. For details on how to connect react with redux, check out their documentation:
https://redux.js.org/basics/usage-with-react
Remember not to confuse the state mentioned in redux with the state in react. Redux state refers to the application state. Do check it out and if doesn't work for you, another alternative would be flux.
I am trying to build a fast React.js app, basically a game.
I need to display 'live' data, but loading them from server using Ajax doesnt feel like the right way to do it. Its React.js, but Ajax isnt the synonym for reacting. I have an idea to use socket.io for this and some kind of backend system for keeping and processing the data, not loading them from database every time.
Is this a good idea or a right way to do a fast React.js app, or am I totally wrong?
Loading data from a server will be faster indeed if loaded from live memory directly instead of traditional database lookup.
Socket.io can be useful if you want to push data from server to client, with server side initiation.
React.js does not make things fast by itself really. It can make development faster.
You can also have a look at Angular-Firebase and 3-way data binding. This is specifically for building real-time applications.
https://www.sitepoint.com/creating-three-way-data-binding-firebase-angularjs/
I am planning to use Qualtrics REST API, in order to get the data collected from a survey. Can i still retain Meteor's reactivity directly thru the rest api or should I save the data from the rest API into MongoDB to enable for real time updates within the app?
Any advice and further reading will be great.
This will sound like a noob question probably but I am just starting off with Meteor and JS as server side code and never used a web api before.
It entirely depends on what you do with the data it returns. Assuming you're either polling periodically or the API has some kind of push service (I've never heard of it before, so I have no idea), you would need to store the data it returns in a reactive data source: probably a Collection or Session variable, depending on how much persistence is required. Any Meteor templates that access these structures have reactivity built in, as documented here.
Obviously, you will probably need to be polling the API at an appropriately regular interval for this set up to work though. Take a look at Meteor.setInterval, or the meteor-cron package, which is probably preferable.
I am new to MVVM , and i wanted to understand ,
if you have a model in the back end, say a c# library which is getting data from the database or any other service. how would the Model notify the viewmodel.
i understand in the MVVM INotifyprovier does that for WPF (just read it somewhere), but how about Web app based scenario, does Viewmodel in java-script always have to ping Model to identify if there is a change in the model and then propagate to UI.
I am assuming that the viewmodel would always have to send Ajax request to a asmx or api with a set interval of 10 minutes or so (just an example).
is that how it works end to end. any example will be great.
Because one of the properties is, automatic UI refresh, so I am assuming that fresh data needs to be asked from server at regular intervals. A lot of examples i see on the web is only interacting between ViewModel and View, but hardly i see any thing with Model, ViewModel and View all combined together.
I could think that if one uses SignalR which sends a ping from Server to the client, then the Viewmodel could be updated and hence the View.
But if every time you need to ask a fresh set of data from Sever, so what's with the hype of Knockout, Jquery has been doing that for a while, except the Declarative binding stuff, in the knockout library.
Appreciate if somebody could correct me.
Thanks
It is up to your client application to fetch new data since server doesn't have any concept of observables. There is also a useful mapping plugin that could automatically map your javascript data from the server into an observable. That way when you fetch data you don't have to re-map your data.
However, it is possible to notify client of changes from server. One way is to make server push changes to the client is via HTML5 WebSockets. SignalR is a good library candidate for that task. It that would open a WebSockets connections so server can notify client of changes. And you would use Service Broker SqlDependency to trigger event notifications on updates. An example could be found here.
Good luck!
Also here is a really good video to watch about knockoutjs that would give you understanding of the framework.