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.
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?
Lets say we have a set of items, that is thousands of entries long.
It would not be practical to load all of them on page-load and have it in the store. How exactly would you deal with this?
Would you just add items to the store, that are actually requested?
What is the best practice here, if an item is not yet in the local store?
Lets say you are 'requesting' an item that is not yet in the local store (but would be available from the api), would you automatically try to retrieve it from the api before returning empty/an error?
Is there any best practice on how to implement this? It seems to be a pretty common use case.
Our should you just try to always load the whole data-set (or at least a minimal version) of it?
Also: what if the items change all the time (other users). Is there even a point in having those items in the store locally, if you need to request it again everytime you want to see its details to not get an outdated version?
Thanks
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.
I'm using Vuex & Vuejs (flux architect) for a CRM single page application.
In contact page i'm showing a list of tasks related to current contact and at sidebar i have a list of task for current logged in user.
These collection of tasks are kept in separate stores. I don't know which is best solution:
After update post request search in both list and update task object if it's present and mutate state.
After update post request use an global event bus and each store should listen and update task object if needed.
It really depends of your requirements, but one thing I can tell is that using two separated stores + bus is defeating the whole purpose of Redux.
If the tasks in your application share the same scope and can be assigned to you or other users that you may be visiting/managing, you can have all the tasks from your scope (your team, for example) and display it on different places using different getters with Array.filter functions.
If the number of tasks is too big to have it all loaded, I'd approach it doing one single tasks list in the store, being populated from a single url.
ie:
- Give me all the tasks I have + the tasks of current user I'm managing
- Give me all the tasks I have + the tasks that matches this search
Although this can get messy if the requirements are more complicated and can get confusing. But try to structure your application with one single store if possible and avoid bus, as it is only recommended for small size applications.
I am writing a mobile mail application and I am using the SyncFolderItems request to sync my folder.
The problem is, that when dealing with folders with a lot of items (e.g. 12000) the syncState becomes huge, and obviously this is not good for a mobile device..
Is there a workaround to this? Should I abandon the Sync operation and use pull subscriptions instead (And perhaps use findItem operation to get the initial id's? )
Thanks!!
What other people say, its a design question.
If you have a lot of e-mail, howmuch do you really need?
I mean, do i need 12000 items on my phone, i dont think so.
Good option is, save all the item id's with subject or something.
When click on the item, get the other properties. And don't save the information, it can be called from the Exchange Server...