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?
Related
For the first i want to sorry for my english. I'm learning domain driven design and trying to implement some concepts in an application i'm working on. My task is not so complex to fully implement DDD on all the levels but i really like it's principles and the core idea and try to use it.
Lets say app is selling books. So i have a Book entity and BooksCollection or BooksRepository. I'm working on frontend and that collection or updates to it is coming from server. And i want to represent it on BooksScreen in BooksList which consists of BookCard. Press on that card for the first calls something like selectBook which changes the selectedBookId in collection and for the second navigates user to BookDetails screen where the data of selected book is represented and the user can do some actions related to domain logic.
The first question is where do i put the loading state of that BooksCollection and according actions to change it ? Loading state is not a domain logic as i understand, it's not an entity status like "todo done" or something. But i need to show a loading indicator in the UI list when the collection updates, error for loading error and success respectively.
And the second is where do i put the the same loading state for single Book ?
I separate it cause for collection i may store that state in some application related class e.g. "BooksScreenState" or something with less stupid name. But what if i decide to show state for each specific card in the UI e.g. that specific card failed to load. Or i have a single User in app and his data can be loading, he can be authorized or not et cetera.
So i can summarize that to something like "how to connect domain and application logic to present a UI".
An interesting question. I don't usually think to apply DDD to the UI level because for the most part, the UI isn't full of business rules and also because I mostly use reactjs and UI frameworks are usually very prescriptive and don't allow much in the way of flexibility.
To answer your question though: If you did want to get a "loading" status in your UI (that's designed using DDD), it'd have to be attached to a "View" object or some representation of the "view"; because that fits the UL (ubiquitous language) better. Think of how you have described it in a little snippet of your question:
But what if i decide to show state for each specific card in the UI
That means your card is an object (entity or value object) that has a enumerable state of loading, loaded, error. You can queue on that object in your UI to display a desired representation of that field.
So, both your questions have essentially the same answer. Since you are loading the UI, your state is only relevant to UI objects and not entities that are in the domain model like "Books" that are represented in the backend. Even if you had a front-end representation of "Books" - like in javascript for example - having a loading state still makes more sense in the view object in the view layer.
Note that there's some simplification/flexibility to this answer because it's also valid for your design to have a View that's an aggregate that contains a Books. Those Book objects could have a "loading" state on them. All of this is still restricted to the UI layer though and such an aggregate and it's specific design will depend on the flexibility your UI-framework allows.
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 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.
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.