I am trying to use the store for as much of my state management as possible.
My user interface consists of hundreds of different entities and more can be added at any time. Each one of these entities will have it’s own dashboard and many options and views. When a user clicks on an entity’s details, I’d like this to be stored in the store for future use. I don’t want to prefetch all of the entities.
Is there a good way to use the aurelia-store in a dynamic manner. The guide assumes you know all entities in the state up front.
The state is just a plain object. It can be extended with further props/entities as they. Actions and middlewares can also be registered at a later time. Whats precisely the issue you are thinking of?
Im not sure I understand exactly your use case but it sounds like you need a slice of the state which is defined via an URL paramter. If so than do store.state.pipe(pluck(urlParam)).subscribe((slice) => ...) where slice will be the plucked part of the state object
the second code listing in the connectTo docs is exactly showing this use case. Instead of a hard-coded string you could pass something along the line like:
new URL(document.location.href)
.searchParams
.get("YOUR-PARAMS-NAME")
That should work. What would be great if it’s possible in future versions would be to have access to the route parameters that are defined during route config. While it’s not hard to grab what I want since I know the url format, if I change the route in the future, i’ll be breaking this function.
@elitemike
I was wondering why you haven’t looked at, or at least mentioned using indexedDb for this?
I have a similar use case for needing to locally cache data, and its nice being able run some simple queries to pull and merge from the local indexedDb.
Just a quick summary of my project. I am creating a system for a local flight training school that has certain features that needed to be offline capable. These would be used in the aircraft while flying, so any data needed in flight would require that to be stored locally, used and perhaps updated in flight, and then sync’d with the server upon re-connection to a WAN.
So I went with a PWA style web app created in Aurelia using a .NET Core WebApi server on Azure. My first iteration is design for full offline support. When the user authenticates I determine what data they can see, load that into the indexedDb, initialize the Aurelia Store to manage current state of objects in the app, but not the data specifically as that is maintained in the indexedDb. I have a check on any router navigation that then checks if online (can access a file on the server successfully to prevent LieFi) and sync any changes available.
In hindsight I think that I should have, and will in the future make some of the functionality online only (admin stuff mainly), but it is working for now for everything.
So I think that state is good for temporary items, or items that are not yet ready to be persisted, but I think that any long term persisted data would be better in the indexedDb in case the user clears cache and the localstorage is wiped(not sure about this, but worst case it would). I do save the state in localstorage on tab closing, and restore on returning to the app for general state, and objects not yet persisted, but its not a significant loss if that gets wiped.
I have a lot of assumptions here, that I hope I am right with. But I am finding the system working very good.
That sounds like a great implementation for your task. For me though, that would be overkill. I have no need to be able to function offline. I’m just looking to build my app in a consistent fashion where most things are reactive. My data on the dashboard MAY not change for hours/days/weeks, but some of it may change every few minutes, it just depends on what the user is looking at.
Understand.
I think the issue I was working around was some browsers when it clears the cache either on demand or when it decides to on its own will remove local storage as well which is where I store state, and I wanted the main data to persist through that.
If your requirement is that you can reload data on each new tab visit to the site then it is not much of an issue.