So, I am building an ecommerce app in sveltekit and wanted to implement cart as a global store, so components can query that store for cart status. I pretty much know how to implement it in a single page application, but can't get my head around how to do it with SvelteKit. What will be the best approach to make a reactive cart for such application? Should I store cart at server only and reload cart on each change? or is there a way to implement a global store that works between pages?
Just import the store to whatever page needs access to the store. It's entirely global.
import { motor } from '../stores.ts';
console.log($motor.horsePower);
Where and how you store the data is a design decision with various considerations: E.g. should it persist when an authenticated user switches devices (e.g. from phone to desktop)? Then you would have to store it on the server.
If the data comes from the server you can probably [load it via the topmost layout load function and put it in a store in a context which pages get access.
To have a fully client-side global store that does not lose state on (hard) navigation you can wrap localStorage or sessionStoage, the latter is less permanent. There are libraries that already implement such functionality or you can build your own (the contract for writable stores is very simple: Provide a subscribe and set function. I give a basic outline of a local storage store e.g. here).
If you need a global reactive store you can use a reactive db. Like firestore with rxjs (rxfire).
The nice thing is: An RxJS Observable can act as a drop-in replacement to a Svelte store.
Here you can find some example code. And no need to reload on each change, because it's reactive with the $store syntax.
Related
I have the following problem in Angular. If I have two pages A and B each containing a table. Then I make changes to Page A in the table, and then navigate to Page B. Now I expect that when I navigate back to Page A, the changes are still there. I don't want to send the changes to the database until I click a save button. What is the best way to solve this in angular?
If you are only wanting to preserve the data for this one instance, then definitely look to using a Service and writing your data to localstorage for it to persist across page refreshes.
If you are developing a SPA, then I'm not sure why you need it to persist across a page refresh since moving between components does not actually send a new HTTP request. You state should be preserved in your Service.
If you find yourself needing to manage state across your entire application and want to do it reactively, I recommend checking out NGRX.
https://ngrx.io/
Another alternative that maybe has a little less boilerplate is NGXS, which does the same thing as NGRX.
https://www.ngxs.io/
I don't recommend to use localStorage for your task if you develop SPA application, because localStorage/sessionStorage is limited and it is designed for another purposes - like authentication etc. But of course if you need to preserve your data - like cookie/JWT token etc. even after refreshing the page you can use localStorage.
I recommend to use Angular services for this: please see examples at docs Services/DI docs. Once you registered service as a singleton Singleton services, you can inject it via built-in DI(Dependency Injection) in component which renders your table at page A. But of course, you are not limited in injection only in component which located at page A, you can inject it even in page B etc.
Let me share the problem with my app:
When user initiates the app, it will directly navigate to Home Screen. While user is in home screen I would like to make bunch of api requests to fill the local db with the data for the "possible" screens that user can go.
In native applications I know that this case can be handled by a different task (parallel programming) however, react native is built in with Js and doesn't support multi threading.
I know there are some libraries that implements WEB WORKER's in react native, however what is the best practice to overcome this problem?
I use redux to overcome this. I will call the api and it will map the data to the redux store. All the screens are connected to the store. Since, the data is already loaded in the store I will just display it.
So I'm working on a react application as a front and as the back python, Django and rest.
I'll do the front part in a few days, but a question spawn: how can I manage all my apps for the user with an account and the other (without the account)?
I look a few options but I don't really know which one is better:
local storage
context API
cookies
For example if the user is connected and wants to see him own profile page, he could without fetch in the code cause it's just a few information like name, email, ...
I don't know if it's enough to clear but hopefully enough to get some suggestions.
Cookies are mainly for reading server-side, whereas local storage can only be read by the client-side.
An other point is saving data, a big technical difference is the size of data you can store, localStorage give you more space.
Context API you'll use it eather you work with cookies or localStorage
You can call the API for fetching information the first time the user logs in, and then you could store the information on the app state for the whole session. If you want to store information between sessions localstorage works just fine, is easy to access. However, you'll have to check if this information exists when the user logs in.
Context API can help you to access the stored data easily by using useContext react hook API in other child components and manage them by React, but localStorage is a way to persists Context API changes with localStorage to get them back after every page reloads(prevent losing data in page refresh). But cookies have a maximum length(I don't know how much is it) which isn't the best way because it has security issues and a use-case of cookies is using them on the server-side by the backend.
So recently I started to implement a database in a react app (like any real world app would have). My question is Why is redux needed? I mean if you have a database you can push information directly in a database and retreive it from there. You don't need to save it in a state. (New to react,redux. This was just my point of view)
Database and state management tools such as Redux have different concerns (although they manipulate the same thing: data).
When a client uses your app, it will first retrieve data from the database. At that point, that data needs to be held in memory in order to display it.
You can decide to use the React Component internal state which is component-scoped. Now, this is perfectly fine if you plan on using the data you just retrieved inside the same component.
As your app gets more complex, you'll sometimes need to use the data in different points throughout your app (e.g. if you retrieve the user info, you'll probably need to display it in the header, in the profile page, etc).
This can be tricky to do using the React Component internal state as (if you've tried React a bit) you know passing data is done by passing props down children components.
The common solution when you need to share data between different components is to lift the state up in your app, so you can pass it down to the different components that need it.
This can be tedious and prone to errors as your app grows.
Redux is the solution that addresses that concern. It helps keeping the state you share throughout your app clear and clean by creating a global state that can be accessible anywhere in your application (among other things).
Redux is a state management tool. Redux is for client state, by default it's in-memory only. It is not a 1:1 mapping to your database data but for your views to dispatch actions and then update the store state so other views can react to those data changes. With Redux, the state of your application is kept in a store and each component can access any state that it needs from this store.
talking to database every time is a php kind of thinking, which puts lots of load on the server with huge number of requests... slowing down everything.
with redux you create a mini store cart & fetch necessary data from database for immediate use and keep all of them with the user and remove the requests to the server for those items.
you need to use database not every time but only when needed... to render the app faster and use less resources.
There are multiple reasons to use Redux while using a database. For example you wouldn't save volatile state in a database. You could see everything that should not be shared between tabs as volatile state, like routing or component states like opened menu or form inputs.
In learning Angular 2, I've seen multiple examples where application data is stored in services.
For example: in a todo-list app, you'd find a "todo" service that would define a "todo entries" list that would become accessible to any consumer of that service.
My question is: Is there a better way of defining application data? Should it be separated from services?
In my particular case, I'd like to make use of localstorage to save a bunch of application data. Eventually, I might refactor this to instead save and load data from a database. Would it make more sense for me to be creating some sort of "data-storage" service that could be used by other services to save and retrieve data, or should data always live with the service that uses it? How might one choose to structure this in the "todo" example above?
LocalStorage is only for improving user experience (caching for speed, or similar) but it's not a place to persist data that must not be lost. For this case you need a server where you can send the data to and which stores it in a database. https://www.firebase.com/ might be convenient for a start.
It is a good idea to separate data from the service that fetches or persists these data. If you use Angulars Http service to fetch and persist data from/to a server, this might be separation enough though. When your application becomes more complex you probably want more abstraction but this would need a more concrete example of what you actually try to accomplish.