I tried searching for "good practices" about how to link complex APIs that needs configuration or be provided by some manager and I can't seem to find how to make a "good" flow of data through redux.
So far I have been thinking of creating a reducer with actions that map each method I can call on a given complex object.
To put more context to it, I am building a framework to interact with a bluetooth device using this library (https://github.com/Polidea/react-native-ble-plx) and the startScanDevice returns me complex objects I can interact with (https://polidea.github.io/react-native-ble-plx/#device) which also holds it's own state (a device knows if it's connected or not for instance, it also knows it's bluetooth services, etc.).
From what I have read, redux state should be having simple objects so it can have time travel properties and ease persistence.
What would be a good design to to store those complex objects and enable interaction between my components, reducers, actions, the store and this API I'm currently working on ?
Currently, I was thinking of giving callbacks to my API that would dispatch redux actions with new data to add in the redux store but I just can't seem to find a proper way to store my complex objects and provide access to it in order to invoke those methods and give them callbacks.
Here's a complete flow example :
Invoking startScanDevice from the plx-ble API and provide a callback to receive device object given by that existing API
receive device objects and store it somewhere
Update redux store with proper information about the device object I need throughout the app
From a reducer, retrieve the device object from step 2 and invoke a method to interact with the device (example read from a characteristic)
Update redux store with read data from step 4
Steps 2 and 4 are the ones I can't seem to find a proper way to do.
Any help would be greatly appreciated !
Redux-thunk middleware could be helpful to you.
Redux Thunk middleware allows you to write action creators that return
a function instead of an action. The thunk can be used to delay the
dispatch of an action, or to dispatch only if a certain condition is
met. The inner function receives the store methods dispatch and
getState as parameters.
to store those complex objects
Don't complicate this.Try to keep your state as flat as possible.
Like
state={
PoweredOn: false,
Device: "deviceName",
//similarly all
}
The more you keep it flat the more it will be easy to modify.
The API doc you linked seems to have duplicate ways of calling these methods for exactly this reason.
For instance, you could connect to the device by calling device.connect(options) or by calling the package method connectToDevice(deviceId, options). The benefit of the second method being that you only need to track the ID value, and have no need to store the entire device object.
Related
This is more of an understanding question and I also want to know the community thoughts, rather than a code question.
We have a React App using redux for managing the global store and redux-thunk for dispatching actions. Now we want to localize the App and add a language switch. For that purpose I created a HOC which uses React.Context to store the dictionary for current language in it. And I wrapped all Components in this HOC - everything works just fine.
But we also need to access to the dictionary in the thunks to e.g. provide success/error messages after API calls in the selected language. It seems to be impossible without passing dictionary into thunks.
I've read a lot about Context API and when to use it and that it has different purpose than Redux. That's why I put the translations in the Context and not in the store, mainly for this reason. But now I'm getting the feeling that I missed something and should actually put the translations in the store instead to not be forced to pass the dictionary to the thunk every time I need it there. Is it so?
Or is there a way to implement something like getContext similar to getState from redux-thunk?
I’m using Redux to manage the logic of a music player. When it’s playing something and suddenly fails, I want to be able to intercept that action and make the player start again, but only n times, as I don't want to keep automatically retrying forever if the problem isn't recoverable.
I think a middleware is a good option to implement this, but I’m wondering if I should store the number of retries already done for a certain item either in the global state, or locally in the middleware.
A more general question would be if a Redux middleware should contain any local state at all, I mean, state that only it cares about.
In my opinion (and based on limited information about your specific project):
you should configure the n value via the middleware constructor, and
you should store both n and totalRetries in private variables of the middleware.
Why?
Choosing where to store your middleware state shares similarities with deciding between component state and redux state. You can use the same questions as a guide:
Do other parts of the application care about this data?
Do you need to be able to create further derived data based on this original data?
Is the same data being used to drive multiple components?
Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
Do you want to keep this data consistent while hot-reloading UI components (which may lose their internal state when swapped)?
As Dan Abramov said:
The way I classify it is when ever state needs to be shared by multiple components or multiple pages and we need to persist some data over route changes, all that data should go inside the redux store.
You can map this idea from components to middleware by rephrasing "…persist some data over route changes…" to "…persist some data over [insert relevant boundary here]…", for example closing and relaunching the app.
The totalRetries doesn't seem to represent a meaningful state of the application. It has to do with some "behind-the-scenes" I/O operation that wont persist across closing the app or sharing app state with a debugger. One might even argue that you should not expose it to other components via redux state, lest they rely on (potentially shifting) internal workings of your middleware.
redux-saga, etc allow us to write this type of functionality in a very neat and testable way without having "exposed wires" in the application state or module namespace. You could use a saga to encapsulate your entire "play audio" behavior.
Exporting a reducer and then accessing its compartmentalized "public" state from your middleware introduces quite a bit of unnecessary complication.
If you want to expose totalRetries and n to other components, you may do so via an action, such as PLAY_AUDIO_RETRY with the action containing both variables in its payload.
I'm working on a React+Redux application. I'm calling APIs through Redux actions and storing the response data in the Redux state. But there is a case, Where I don't have to store the API response data in the Redux store.
So the question is, Is there any valid reason to call the APIs through
Redux actions or Should I call the APIs directly since I'm not storing
the response data in Redux store?
It depends on what kind of call you're trying to make, and who's concern it is.
Here are a few cases:
Is this a one-way call to track something?. You can fire an action that gets picked up in a middleware. this is a good case for sending analytics.
This doesn't have to be stored in Redux's store.
Is this a call where some other part of your application will need this data?, then this is a good use case for making an update in the Redux Store so other components when read this and use props to decide what to render etc.
Is this a call where it only concerns one component or isolated part?. You can make this call inside the component in componentDidMount since this doesn't concern anyone else
Alternatively take a look at Sagas, they observe all actions that get dispatched and decide what to do with them in a clean way.
The accepted answer quite well explains the scenario where from API call can be initiated. For better user experience, we always show some spinner or busy sign to inform the user that a request is being made and it has not finished yet. It may happen that API response is not mutating the state, but to let the user know some task is going in the background, we usually update store (for global access) or state (for component level access) with value like isFetching or anything meaningful.
So, it depends on the developer, whether he/she want to show some busy sign or silently perform the API request. Moreover, if they want to show busy sign then, they should decide which part of the application should be aware of the API call. If it is restricted to the component level only, then no need to make the call in actions, otherwise, for global level, yes it should be inside action.
For the sake of uniformity, you should always follow the redux way, even though all the responses are not stored in Redux. It is also a question if you are not using the response from an API call why are you making the call. This argument is counter-intuitive. If you are using the response in some way better do it the Redux way. It is advised to always store the response to a call to Redux and use it, I am sure you are making API calls to do some action on UI.
Flux design pattern has been such help in simplifying my web application. However I ended up directly calling web APIs for certain situations simply because Flux seemed such overkill for the job. I was wondering how others might have solved such problem in a Flux way.
As the diagram suggests, we created the Action via the Action Creator for all Web API calls. I will give an example scenario. Let's say there are 3 components that are interested in User Store changes at the moment. User clicks one of them to load a list of user's hobbies from the back-end. But I only want only that one particular UI component to display the list of hobbies due to the user's action. The other 2 components won't change at all. Traditionally this would have been a simple couple lines asynch call with a callback. If you are to religiously follow Flux for this,
You create an action via Action Creator with a specific reference ID
Fetch data via Web API
Upon receiving data, action is created using the Action Creator
User store listens to this result arriving via the action
Update the store
Fire store updated event, all 3 components react to that and check if that was for mine using the reference ID
then finally render with the data fetched in that 1 UI component
My app having many small parts that load data dynamically like this per user action, I decided to use Flux for things that many components have to share states with since the stores act as centralized state provider. How do you guys use Flux to do simple data fetches such as the one mentioned above?
There are couple of ways to solve this.
Let all the components receive the update and the component decide whether to update or ignore the update.
Split up your store and subscribe only to those which are need in the component. This approach can get messy with stores getting dependent on each other and simultaneous dispatch problem.
If you haven't used any flux library , redux is highly recommended. It solves this by allowing the components to subscribe to part of state(store) tree.
I'm currently not happy with the hacks I've come up with using Flux, and now Redux for populating initialState in my store.
I always send a payload of JSON down with the initial page load. Universal JavaScript is not an option in some of my applications as they are not all backed by Node. I would like to focus on "best practices" and patterns around how the data is preloaded on the client. Then, I feel that moving to the server is trivial.
Here’s a gist of what I’m currently doing at work and in a few other toy apps using Redux:
https://gist.github.com/kevinold/5767bb334472b7e2bfe3
To summarize:
I’m sending global variables down with the page
In componentDidMount() I'm dispatching actions that “receive” and handle the various pieces of data. (These “receive” methods are used when processing these bits of data when they are fetched async via a request action, and I’m repurposing them here since I already have the data.)
This works and there aren’t any issues that we’re running into, but it feels like a hack I’m not really happy with. Also, I feel that the initial state of Redux isn’t happy with me doing it this way.
According to http://rackt.org/redux/docs/recipes/ServerRendering.html and the section “The Client Side”, I am able to pass initialState to my store.
Here’s a patch I have for another project I'm helping with (KeystoneJS). I'm passing it's Keystone object into the initialState:
https://github.com/kevinold/keystone/commit/6f80c2f6f1e5c081361369a8bb31b75f1e62460f#diff-cd8e9933209e834b0519a0257bcfa914R8
While that does work, as you can see, I’m forced to match the shape of the output of my overall combinedReducers (https://github.com/kevinold/keystone/commit/6f80c2f6f1e5c081361369a8bb31b75f1e62460f#diff-b4b498ca92c4d05e050b45c725c26f9d) or I will get console warnings, etc.
I might be extremely lazy in dealing with this, but trying to limit having to update another piece of data when I add/change anything related to reducers (add a reducer, how they are composed, etc.).
I realizing I might have to in order to get this initialState into the reducers properly.
I'm currently digesting how (https://github.com/erikras/react-redux-universal-hot-example/blob/master/src/client.js#L25) handles it's initialState.
I’d really appreciate some feedback on "best" and "real world" practices that are working for others.
I don’t fully understand the question but I’ll try my best to answer.
In componentDidMount() I'm dispatching actions that “receive” and handle the various pieces of data. (These “receive” methods are used when processing these bits of data when they are fetched async via a request action, and I’m repurposing them here since I already have the data.)
This is a bad place to dispatch them. If you choose to dispatch actions instead of prodiving initial state directly, do that before rendering. In other words, do that right after creating the store! This way you don’t render the initial blank state.
While that does work, as you can see, I’m forced to match the shape of the output of my overall combinedReducers (https://github.com/kevinold/keystone/commit/6f80c2f6f1e5c081361369a8bb31b75f1e62460f#diff-b4b498ca92c4d05e050b45c725c26f9d) or I will get console warnings, etc.
You’re not supposed to create the initialState object manually. You’re supposed to create a Redux store on the server, dispatch actions there to prefill it with data, and when it’s ready, call store.getState() to retrieve the state you want to pass down to the client. On the client, you’d read it from a global variable, and create the client store instance with it. In other words you never have to manually create initialState—you’re supposed to grab it on the server with store.getState(), pass it to client, and create a store with it.
Therefore I don’t understand the problem you describe. If your reducer names or nesting changes, it will change on the server too. There is nothing you need to do to “fix it”—if you use Redux both on client and server, their state structure will match.
I’d really appreciate some feedback on "best" and "real world" practices that are working for others.
If you use Redux on server, prefill the store as described above, and pass its state down to the client. In this case you need to use the initialState argument of createStore().
If you for some reason don’t use Redux on server but you want to prefill the data anyway (e.g. maybe you use something other than Node), the approach with dispatching actions is your next best bet because it doesn’t require your backend to know the state shape. In this case, you should pass those actions as JSON to the client, and dispatch() all of them right after the store is created.