I'm not a frontend developer and have not used react or any flux implementations as I'm not sure if they will do what I want. I'm trying to wrap my head around how to use react to render backend changes that are external to the client, ie changes by another user. I see how react works to handle the view when the client takes an action, but I'd like to render changes from the server/other users without long polling (similar to how meteor works with two-way data binding).
My solution was to create a pub/sub system on the backend that will push changes to the clients if they're subscribed to the appropriate channel. This could be accomplished by analyzing database queries/backend actions and their resulting changes as is done with Asana's Luna. My friend told me that I can simply do this with only using an implementation of flux. If he's correct, I must be misunderstanding what flux actually does. To me, it seemed that it only reflects changes based on the actions of the 'current' client.
You are right. Flux is simply a way to manage application state in response to different actions. How you would trigger those actions is out of its concern. pub/sub server in this situation is a right way to go. You can take a look at Firebase - google non relational database that has lots of SDKs for different platforms and can notify client of changes done by other users. But anyway it works as a pub/sub server =)
Related
Data usage really matters for my targeted users. So, I am looking for an APPROACH that'll help me reduce the number of data fetching during react rerender cycles in React and React-native App.
Let's say I have a page that renders all the Items fetched from an API. Since the API's data can be updated at anytime, I am obliged to re-call the API whenever the user displays this page.
IS THERE ANY WAY FOR ME TO KNOW THAT THE DATA HAS BEEN UPDATED WITHOUT BEING OBIGED TO RECALL THE API?? Because I think that the less HTTP requests I send the less mobile data I consume (Maybe I am wrong... I don't know)
I thought of implementing a solution with Redux and Socket.io :
I wanted to prepare an event called data-updated that will be managed by socket.io and whenever one of the users performs an action that updates the item lits (The API data), the data-updated event will be triggered and all the connected users will be notified. Then in the data-updated event handler I will update the item list state slice in the redux store.
My worry is that since socke.io keeps the connection between users and the server alive during the whole session, Won't this approach consume even more Mobile data than recalling the server at any rendering??
You can proceed with graphql with mutations and its caching mechanism, its pretty cool and if I mention if it is handled efficiently you can run your application in 2g network also with speed. Checkout its usage and advantages over REST you gonna love it. https://graphql.org/
Another way is by using redisCache but personally I've not used it though you can check.
You can use React-query lib for data fetching, updating, caching etc.you can read more about it but read its docs.
https://tanstack.com/query/v4/?from=reactQueryV3&original=https://react-query-v3.tanstack.com/
currently I am using redux in different projects for state management. A few days back, I listened about react-query which is also used for state management and provides caching and async fetching. I am trying to figure out the main difference between these two libraries.
Where I should use react-query and in which cases I need redux.
React-query is what you would call a specialized library. It holds an api cache for you - nothing else. And since it is specialized, it does that job quite well and requires less code.
Redux on the other hand gives you tools to just about store anything - but you have to write the logic. So you can do a lot more in Redux, but you'll have to potentialy write code that would not be necessary with a specialized library.
You can use them both side-by-side: api cache in react query, rest of your global state in Redux.
That said, the official Redux Toolkit also ships with an api cache abstraction RTK Query since version 1.6 with a similar feature set as React Query, but some different concepts overall - you might also want to check that out.
react-query is designed to deal with data that is stored on a remote server. To access this data, your app needs to use asynchronous requests. This is where you probably want to deal with caching, loading state, network failures, etc.
That is where react-query shines.
Redux on the other ends deals with data on the client-side. For example the content of a text input or the state of a modal. You don't need to deal with network-related issues. But you do need to deal with complex sequences of causes and effects.
That is where redux shines
Redux and react-query are 2 very different things: react-query is used for data synchronization, Redux is a global state manager. react-query is used to keep synch all your apps to the same db, Redux is used to share a part of the app state to all the components that need to read that state.
An example: I have an app to chat with other users. With react-query I keep all the apps synch with all the messages users received, then I store the messages in Redux in order to have messages on chat page and on history chat page.
React Query manages Server State. Its main function is to handle functions between Server and client.
Redux handles client-state. Redux can be used to store asynchronously Data.
So, they have their unique role at different levels and both can be used side by side.
React-Query = server state library(save/cache api response)
Redux = client state library(globally accessible client state
should be stored).
We should distinguish between two kind of states, client state & server (or remote) state:
client state contains:
locally created data that has not yet been persisted to the server.
UI state that handles active routes, selected tabs, spinners, pagination controls, and so on.
server state is everything related to:
data persisted remotely that requires asynchronous APIs for fetching and updating
When it comes to client state, Redux is a grate management tool for managing application’s state.
On the other side, to manage server state, we can use regular state management tools but they are not so great at working with async or server state. So, to resolve this, we use React Query. As described on their documentation, React query is a great tool for:
Caching... (possibly the hardest thing to do in programming)
Deduping multiple requests for the same data into a single request
Updating "out of date" data in the background
Knowing when data is "out of date"
Reflecting updates to data as quickly as possible
Performance optimizations like pagination and lazy loading data
Managing memory and garbage collection of server state
Memoizing query results with structural sharing
You can simply to think:
React Query = axios + cache logic
Redux can store synchronized data and asynchronized data
By the way, I use context manage synchronized state, React Query manage asynchronized state now.
It's days or maybe weeks (reading articles, watching videos/talks) that I'm trying to understand how to use Redux and redux-form correctly but it's really hard for me to fully grasp the concept. Maybe my usecase is not well suited for Redux or maybe I'm simply missing something obvious.
What I'm trying to find is a good foundation for a large application. I'm fairly convinced about React, but Redux (and in consequence, redux-form) seems like a good solution for a problem that I'm not having. Still, everybody praises the Redux (or flux) concept, so I want to make sure that I'm not missing something.
Well, the application is heavily database-driven with all data readily available in the browser (it's a offline-first application).
I'm using a in-browser database very similar to NeDB plus a Mongoose-like ODM, but actually the database is a(nother) custom project that I want to open-source once it is stable enough (I do have implemented it already and it works very good so far).
The key points of that database (relevant to this question) are probably that it has all data readily available in the browser and that it supports "live queries" - that means that I can subscribe to database changes and up-to-date query results are pushed directly to any consuming component/handler. Furthermore, the database automatically synchronizes all data with a server in background (two-way), meaning that collections may change contents in any moment.
As UI frontend I'm using Material UI.
The application itself will manage quite a number of different collections and I need to implement a number of forms for the user so that he can edit single documents in certain collections. Depending on the context in the application the user will see a list of all documents in the current collection and alongside a form showing the details of the currently selected document in that list. That form will of course also allow changes of the document. The user will probably only edit (see) one collection/form at a time.
See this quick Mockup for easier understanding:
The list on the left is ridiculously easy to do with React and the live queries described above. It's also "reactive" in that it is always in-sync with the database. However, it doesn't currently use Redux at all. I'm not sure if that's bad or not.
When clicking any item in that list, the details should show up in the form on the right.
I like the redux-form (v6) concept, but I can't figure out how to feed the document data to the form. I know there is initialValues but I could not understand how to use it properly.
I guess I need to push the document data somehow into Redux so that it is reflected in the form. Do I need to "start" a Redux action to push the data into the store?
On the other hand, using classic React state to pass the document (a simple JS object) from the list to my form component seems radically simple to me. At the moment I don't see any benefit from having a global form state in the Redux store. But then, I probably need something else than redux-form (couldn't find anything comparable).
Redux with my database seems also redundant to me since in the end both are global data stores.
I do use Redux already for a handful states that have nothing to do with database contents, like application status indicators and to toggle a global drawer. I'm also using redux-router (and ultimately would like to link the current list selection an unique URI). Yet I'm having a hard time to find a harmonic link between Redux and the database/database-related components.
So, my question in the end is: What's a reasonable way to implement these parts of the application? Redux or not Redux? In either case: how can it implemented?
If all your data is available more or less synchronously locally, Redux might not be that great a fit for your application.
However, if you want to use Redux Form, which provides a lot of form state management out of the box, you will need to use Redux, even if you only use it for the Redux Form reducer.
To initialize your form, you can either pass the values in via an initialValues prop to the decorated form component, or you may also call dispatch(initialize(formName, formValues)) yourself.
you can use the following package I've written:
https://www.npmjs.com/package/redux-offline-wizard
the base idea is to:
1) save redux to browser storage and rehydrate (reload from storage to redux store)
2) add a new branch to redux store to implement an outgoing queue for requests. any async XHR action will add a request to queue. Queue requests will be sent when user is online or comes back online and will be retried if failed because of network conditions
Lets say we want to have one instance of the application and multiple tenants trying to access same features but also have some level of customisation and of course data isolation. In short Basic SaaS model.
Tenants will probably be identified by subdomain/domain and/or by querystring.
So the main question (which is rather specific):
What are common approaches onto implementing a multitenant environment using React + Redux ?
Thinking loud:
How to approach/structure the Application Store.
How to deal with tenant specific configurations
Do I need to have some sort of a TenantContext available somewhere at hand.
How to ensure proper level of isolation and avoid race conditions?
What else should be kept in mind while developing it?
Any thoughts, ideas, past experience, advice, are highly appreciated.
Thank you!
A typical Redux store usually only reflects persistent data, and contains application-specific data, like which tab is active or what is the value of that field. But in case of persistent data, that's an interesting question. I believe React and Redux are simply not for that. But even though, there's an interesting solution for that: Relay and subscriptions.
Relay connects your components to a GraphQL source of data (typically remote), and then you simply access props that are seamlessly injected into component and given values from the data storage. With subscriptions, any update in the data storage causes its delivery to a connected component via a subscription established between the app and the GraphQL server.
Now, you can add an extra layer for multitenancy and synchronize data between nodes on a lower level, completely unrelated to React. The only thing now is that you'll need to listen to every update and send subscription updates, and there's no nice "single-click" solution for that yet.
You can see this discussion to get an idea how you can update a subscription. Good thing is that, on the client-side, the app will simply react to updated props with a connected component being re-rendered with new props.
I have been reading about React and Redux lately. It looks very interesting and I'd like to use it for small personal projects. One question I keep coming back to is, when does data get saved to the database (or some sort of persistent storage)?
Most tutorials explain components, props, state but they I've not found a lot of solid information about saving said state to persistent storage. Some articles mention local storage but what happens when that is cleared? All the user's data is gone . . . ?
Eventually, a database has to be used at sometime, right?
I have been looking into Axios to help with the API backend. Is this a good option? Is there someway to save to local storage instead so the user sees the UI update instantly and silently call an API endpoint after the fact?
Open to ideas and suggestions. Thank you!
This really is a broad topic but you're right that the internet is lacking in examples of data persistence. One reason is that neither react nor redux are frameworks that help with these; meaning it's a great application of the libraries but are not core to the abstract ideas they present.
That's not to say it's undoable, quite the opposite. With the help of redux middleware this becomes a fun task that works flawlessly with the rest of your application. There are many different ways of implementing data persistence so I'll just explain one here, which I use in my own apps.
CouchDB + PouchDB + middleware
CouchDB: simple document storage in JSON format
PouchDB: syncs your localStorage with a CouchDB instance to automagically allow offline use
Since databases introduce stateful behavior, redux suggests using middleware to not muck up your store with state kept outside itself. In this middleware you would sync up your DB instance to the store. This middleware simply reads the data in the DB and fires actions to insert it into the store. Your application then fires actions that the middleware picks up and uses to store data in its DB. Finally, the DB updates the store with the new data it inserted/updated/deleted.
It's a simple yet powerful way to persist JSON serializable data to a DB while maintaining a redux store.
Use react-persistent-store-manager. Uses pull state and localforage for persistent data. It's quite straight forward.