I ve started to work on reactnative - redux project. I am totally new on this functional paradigm. My question is simple: I have different login/signup options and one of them is facebook.
Inside my action file, i get token from facebook. I should send it to the server for checking. This request can return multiple results
This user is new, open new user page
This user already exist and approved, open application page
This user already exists but hasnt approved sms verification yet, open sms verification screen.
and the question is; where should i put those logic? Should i done it all on actions or just send events to reducer and let it decide. I am confused about that.
Thanks
Per the Redux FAQ entry on "where should my business logic live?":
There's no single clear answer to exactly what pieces of logic should go in a reducer or an action creator. Some developers prefer to have “fat” action creators, with “thin” reducers that simply take the data in an action and blindly merge it into the corresponding state. Others try to emphasize keeping actions as small as possible, and minimize the usage of getState() in an action creator. (For purposes of this question, other async approaches such as sagas and observables fall in the "action creator" category.)
This comment sums up the dichotomy nicely:
Now, the problem is what to put in the action creator and what in the reducer, the choice between fat and thin action objects. If you put all the logic in the action creator, you end up with fat action objects that basically declare the updates to the state. Reducers become pure, dumb, add-this, remove that, update these functions. They will be easy to compose. But not much of your business logic will be there. If you put more logic in the reducer, you end up with nice, thin action objects, most of your data logic in one place, but your reducers are harder to compose since you might need info from other branches. You end up with large reducers or reducers that take additional arguments from higher up in the state.
I also discussed the idea of "thick" and "thin" reducers in my blog post The Tao of Redux, Part 2 - Practice and Philosophy.
Related
I'm very new to React + Electron. I'm wondering where most people store basic, component-specific state.
Scenario: I have created a custom component. Basically a type of table. The relevant bit of this table to the question is that I allow users to show/hide columns, or even modify the column order.
I'd like these 'column settings' to persist even if the user closes and reopens the application.
No other part of the application is interested in the column settings. They simply affect what is shown in the custom table component.
The underlying data model is not affected by these settings.
I've looked around at a bunch of solutions. Most will probably work, but not sure which is appropriate.
Redux: I could store these bits of component state there. However, the Redux docs give the impression that it is more targeted towards storing global app state. No other component in my application cares which columns the user chose to hide in this table. Thus, it would seem like a gratuitous use of Redux, when this probably should be something handled locally in the component irrespective of whether Redux is present or not.
Localstorage: This would probably work. Main concern is if the user decides to run multiple instances of the app. There could be a vanishingly rare race condition if both instances decide to save the column state at the same time. I don't consider restricting app instancing a proportionate solution just for something as trivial as these columns settings.
electron-store: Says it does atomic writes. But what if I want to use this component one day outside of electron (say in a web app nb: this is very low priority consideration - i'm very unlikely to use it outside of electron)? Should I tie the component to electron just for this? Also, is using ipc (since e-s lives in the main proc) to save trivial settings like this overkill?
What do people do for this?
I'm new to react-native and redux and I'm creating an app that consists of a survey page and a main page that would display other users depending on how they answered the survey. I use firebase to take care of user authentication and to save the results of the survey and redux to handle the state. I started with hardcoding each question and input field then each question has its own action and reducer to update the state on each change from the user (such as typing a letter for the first/last name field).
The survey component has grown to a point where I was considering using firebase to store all the questions and answers and having the component fetch the data then generate the survey. However, since I'm using redux I'm not sure what the process is for dynamically creating actions and reducer or if that would even be a good option. My thought process for using redux was that all my pages could grab the data from the global state since they aren't connected through a parent/child relationship and I use react-native-router-flux to navigate between pages.
TL:DR: I want to store questions and answers to a survey in firebase and have my component fetch the data and create the questions but I'm not sure what the best practice is for saving the state if I want to use redux since I want other pages to have access to this data.
I'm trying to implement a feature that would show if items have been read or unread in my app. Say for example a user would open a certain unread item, the item is then marked as "read" and it should stay "read" until the app is either uninstalled or the app data is manually cleared.
I'm wondering what would be the best practice for implementing a feature like this. Is there a way I can hold this info in my state, and somehow have my state persist even after the app closes? Or should this be done through AsyncStorage?
For persisting your store data, try redux-persist - works pretty well & straightforward. It internally uses AsyncStorage as the storage engine.
Where are the items coming from?
How you'd solve this problem depends on your implementation details.
Is this an email-like item, where each item is specific to a user? Then the best place to persist state would probably be in the cloud, as part of the item itself. {messageid: 1, userid: 'xyz', read: true}
Is it a chat-like item, then it's probably also best to persist the state on the server.
Is it a mass-notification, then perhaps the best place would be async storage.
Another factor to consider, but not mentioned is how to handle the same 'item' read/unread state across multiple devices. Does it need to be consistent, or could it be read on one device and unread on another?
Regardless of your specific implementation details, I hope this gives you enough to chew on and will point you in the right direction.
I just discovered feathersjs and really like the idea behind it, even though I'm still unsure how the service-based philosophy can fit for applications which are more complex than a simple CRUD UI.
In order to better understand it I made up an example: Consider an application where you can create and share surveys. You could easily manage to create a survey service to create, update and get the properties of a survey (i.e. questions and answers). But how should one handle the following aspects:
1) There are actions, i.e. service invocations which do not affect the data at all. One action could be to send a reminder email to all invited users who did not participate on a survey yet. If not using feathers I would created a dedicated express endpoint for this, but how do those actions fit in the feathers philosophy? Should one create a service (only implementing one HTTP verb) per action? This will get confusing soon. Use hooks that detect updates on virtual fields and trigger the action? Hard to document and confusing as well.
2) Imagine users could add comments to a survey. The comments would be part of the survey model (I'd use MongoDB for that, so consider each survey object to have a comments array). The client web would invoke the GET /survey/123 method on the survey service which would return the comments amongst the other properties (question, answers, ..). But what about adding comments? Should I use a dedicated service for it, or how would this fit into the survey service? How would such a request look like?
From the Feathers slack channel: https://feathersjs.slack.com/messages/C0HJE6A65/
Sending an email is fine in a hook. For actions you could do a patch with a certain action attribute and then use hooks to determine which action should be performed, etc. The other way would be a simple small service that only has create implemented. For comments I would probably have a comments or survey-comments service and then your survey/123 could populate the comments. Or the web could make 2 calls, one to fetch the survey, the other to fetch the comments.
Let's say I have this blog app. There are posts, pages, menu, and user login.
One way to load the entire application state is to have one api call which will include posts, total number of pages for pagination, menu items and current user state.
The second way would be to have multiple API called, one for each component. So one call for posts and pages, one for menu and one for current user.
Which would be best strategy given the fact react is built around components?
I'll add my 2 cents as answer but still wanting to close as primarily opinion based.
The way I structure my React apps is to have a top level components called Screens or URLs, ie., /list-users should map against the ListUsersScreen component.
In said screen I declare a static method called fetchData, this method returns an object which values are Promises.
{
users: fetchUsersAction(),
someOtherApiData: fetchSomeOtherAPIData()
}
This lends well to both pure client apps and universal apps, as well.
On your server side you'd have to wait until all Promises resolves until you can render something.
Furthermore you can easily cache the values in your application state object and decide if you want to fetch new data or render stale data, also it saves on bandwidth for your user since the user might or might not decide to continue browsing your site.