I was wondering what the best practice or convention is when creating stores in Flux when working with an API
Let's say we have a list of 'projects', the API call would eventually fill a Store called ProjectStore in _projects
Then, when a user selects a project, you want to load the Project specific data. Would you add this to the same ProjectStore as _activeProject, or create a seperate Store for it?
Same for when you load the Todo's within that Project. It would make sense to put these in a TodoStore, but what about a specific Todo within the Todos within the Project?
I hope the above makes sense :)
I would use the ProjectStoreto store both _projectsand _activeProject.
I have done as a rule in my React projects to create a new store for each model.
For instance: Let's say that I have an application that serves messages and accounts. I would then have a MessageStoreand an AccountStore. Then use these accordingly to their domain.
E.g., when I want to get some messages from the backend (through an API), I store them in the MessageStore. The same goes for the AccountStore.
As your project becomes larger and larger, you would probably have to reconsider refactoring something into a new store. For instance, if you want to add advertisement to your site, you could create an AdsStore.
My rule of thumb is to try to separate stores by their domain, but don't make the structure more complex than it has to be.
Hope that helped.
Related
I have created a component in the components section and named it "hero_type_1", now I want to create a parent component and want to use the previous component as an attribute but now I am unable to see the added component in the existing components select box.
After going through the Strapi forum I got to know that that I can add it manually in the json code, but just want to understand why it is not available there in the list and how can I make it available here without doing anything manually. Thanks :)
i think strapi only supports nesting of components up to 2 levels deep in the admin dashboard. You can do more levels, but you would need to do that manually in the schema JSON files and are not able to manage these components via the admin dashboard.
They said it is because of performance concerns, but personally I think it would be a must have, since it's extremely limited with only 2 levels, but I do manage these via the JSON file, since there is no easy way to change that for now.
I'm starting to learn about vuex. I have the question should I set this data from the Store or should I load it on the component?
For example, In my app, I load all users (firebase) from a Store Action and read it from the Getters, but when it comes to load one user data, should I fetch it from the state and then to the component or from the component itself?
I just want to make sure to make my life easier when updating or adding a new feature on the app.
Your store should be your only source of truth for global state.
This means that any component that read data should read from the store. This ensures consistency. Of course each component may need some local data, that it gets using other means and can alter the data that it gets from the store, but it should read from there.
Now you only have a dilemma regarding who should write to the store (using mutations and actions). This depends heavily on your use cases. It is perfectly acceptable to write from the components itself.
There are use cases where populating some data from outside any component makes sense. Probably the most common case is auth credentials. It is easier and cleaner to populate auth credentials before mounting the app for instance so you have one choke point for dealing with authed/unauthed users.
Bottom line is, writing to the store depends on your use case and there's no silver bullet here.
I'm working on a large project built with vue. We are using vuex as the state management system but their are some components where I don't need to access their data anywhere else. So, Is it right to store this data in the component data or stick with the convention and store it in a vuex module.
Thanks in advance.
You need to use Vuex store if the data must be accessible by multiple (independent) components. There are several reasons why you shouldn't store everything in Vuex store.
First things first complexity! If you are building a complex Vuex store you can not use effectively as your project grows.
On the other hand if you're filling your store with unnecessary states, all the states will executed in the first load in the initial JS and the more data will increase the payloads and that occurs longer load of the webapp.
So the best thing what you can do it is keep your local states locally until is it possible, und use Vuex when the communication of independent components is needed.
You can keep data with in your components. You can convert your non data sharing components to Functional Components link here.
Vue process functional components faster than normal one. By converting to functional one you will gain some performance boost.
It is totally fine to keep data with in the components if you don't need to access it globally.
When you create more than one Function Components, You must create keys for them too. You can find the whole conversation here. I gave all the details there with code samples as well.
ENJOY CODING....
I have an app that uses a sync API to get its data, and requires to store all the data locally.
The data set itself is very large, and I am reluctant to store it in memory, since it can contains thousands of records. Since I don't think the actual data structure is relevant, let's assume I am building an email client that needs to be accessible offline, and that I want my storage mechanism to be IndexedDB (which is async).
I know that a simple solution would be to not have the data structure as part of my state object and only populate the state with the required data (eg - store email content on state when EMAIL_OPEN action is triggered). This is quite simple, especially with redux-thunk.
However, this would mean I need to compromise 2 things:
The user data is no longer part of the "application state", although in truth it is. Since the sync behavior is complex, and removing it from the app state machine will hurt the elegance of the redux concepts (the way I understand them)
I really like the redux architecture and would like all of my logic to go through it, not just the view state.
Are there any best-practices on how to use redux with a not-in-memory state properties? The thing I find hardest to wrap my head around is that redux relies on synchronous APIs, and so I cannot replace my state object with an async state object (unless I remove redux completely and replace it with my own, async implementation and connector).
I couldn't find an answer using Google, but if there are already good resources on the subject I would love to be pointed out as well.
UPDATE:
Question was answered but wanted to give a better explantation into how I implemented it, in case someone runs into it:
The main idea is to maintain change lists of both client and server using simply redux reducers, and use a connector to listen to these change lists to update IDB, and also to update the server with client changes:
When client makes changes, use reducers to update client change list.
When server sends updates, use reducers to update server change list.
A connector listens to store, and on state change updates IDB. Also maintain internal list of items that were modified.
When updating the server, use list of modified items to pull delta from IDB and send to server.
When accessing the data, use normal actions to pull from IDB (eg using redux-thunk)
The only caveat with this approach is that since the real state is stored in IDB, so we do lose some of the value of having one state object (and also harder to rewind/fast-forward state)
I think your first hunch is correct. If(!) you can't store everything in the store, you have to store less in the store. But I believe I can make that solution sound much better:
IndexedDB just becomes another endpoint, much like any server API you consume. When you fetch data from the server, you forward it to IndexedDB, from where your store is then populated. The store gets just what it needs and caches it as long as it doesn't get too big or stale.
It's really not different than, say, Facebook consuming their API. There's never all the data for a user in the store. References are implemented with IDs and these are loaded when required.
You can keep all your logic in redux. Just create actions as usual for user actions and data changes, get the data you need and process it. The interface is still completely defined by the user data because you always have the information in the store that is needed to GET TO the rest of it when needed. It's just somewhat condensed, i. e. you only save the total number of messages or the IDs of a mailbox until the user navigates to it.
I am fairly new to Angular and trying to build an Angular application.
I have a lot of data that needs to be used by multiple controllers throughout the app. As I understand it, that is the perfect situation to use a service.
I am planning on storing this kind of data in services. For example I plan on having a users service which all controllers that need user data will inject.
I would like the users service to hold the master list of users and any controller that needs users to just use the one instance of service list.
I am having trouble envisioning the pattern though. I mean:
1) What is the standard way of having the service refresh its data from the server? I realize that I could just go and request the entire list of users every 10 seconds from the server but that seems kind of heavy weight...
2) Ideally I would like to be passing around only a single instance of each user. This way if it gets updated in the service, it is sure to be updated in all of the controllers. I guess the other option is to have the service broadcast an event every time it updates a user? or to use watchers?
3) What is the pattern by which the controllers interact with the service and filters? Do the controllers just request data from the service and filter it in the controller? The other option is to have the service do the filtering. If so how do I communicate the kind of filtering I need done to the service?
I think that by using some kind of solid pattern I can take care of alot of these issues (and more that I am sure will arise). Just looking for advice on some common patterns people employ when using singleton services.
Thanks in advance.
Answer to point 1. A service is just a singleton. How you store and refresh data into it has nothing to do with its nature. Not sure why you want all user data inside a service (unless you are building a user management app), but you could use several techniques like polling (eg. using $timeout ask for new users and append them to the existing ones) or push (eg. socket.io/signalR which will push you the payload of new users when available). This can be done both inside the service itself or by a controller that will add/remove data to the service (eg. a refresh users button in the UI)
Answer to point 2. You can bind/use the reference of the data inside the service directly into your controllers using a getter so that changes to the data are shown instantly (given that are two way binded, if not use events).
Answer to point 3. You can apply filters inside the controllers or in the view it self (not recommended). You can also have a function in the service where you pass the filter or filter params and get the filtered copy of the users collection back (since you will be using the users collection directly in many controllers at once you shouldn't modify that, unless that's desired). If you are reusing the same filters again and again across the controllers you can have a function for each filter that returns the filtered collection with a "hardcoded" filter. You can even have helper function in the service to help you assemble complex filters or have multiple copies of the collection already filtered cached(if you find you are using the same filter again and again)