Giters

joshnuss / svelte-persisted-store

A Svelte store that persists to localStorage

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Persistency in cookies

bertmad3400 opened this issue · comments

commented

Would there be interest in implementing a solution, which would allow for the persistent store to save to cookies instead of local or session storage? I need this functionality in my own codebase (and would imagine I'm not the only) and I'm considering whether I should write some local code or write a PR for this project instead

Edit: Obviously, this would require a little more complexity, as we can just use the standard storage interface, but I think it should be doable by writing a custom interface to cover both storage and cookies

commented

Hi @bertmad3400,

Yes, it is something I am considering.

I built a prototype: https://github.com/joshnuss/sk-cookie-store-experiment

The questions up in the air are:

  • Should it all be part of the same package?
  • Should it support SvelteKit too? (my experiment covers that)
  • Should there be separate "adapters" or factor functions for create a cookie, session storage and local storage store. Since cookies have a bunch of options (expiration, security, path etc)
commented

Awesome! Great to se you already have a prototype working. To hopefully come a little closer to some answers, here is my thoughts on the concept:

  • From the perspective of an app developer, I absolutely think it makes the most sense for it to be part of the same package. As a developer not working on the library, but on my svelte application, I don't care that the underlying API's (storage and cookie API) are different, I just care about that the store has a persistency mechanism. This would also allow to use the same interfaces for things like serialization
  • With that said, to keep code complexity minimal, I think we should create a different object factory for cookies. Not only does it need other options as you mention, but I would imagine the usecase to be quite different (I often initiate localStorage stores from static application code, but would probably initiate a cookie store from load functions to ensure it can read the cookie server-side to enable SSR with the information)
  • I'm not a 100% sure what you mean when you ask whether it should support sveltekit? I assume you hint to the fact that the code you have written in the prototype uses AsyncLocalStorage to also work server-side, in which case I would argue that, no, this doesn't actually make sense. If I would want to use this cookie server-side, it would be to allow for data in the store to be used for SSR, in which case the implementation in the prototype doesn't solve this, as it can't read the cookies from the incoming request. What I would propose would be to implement a clientside only cookie store, and then initialize it from the load functions using the sveltekit cookie object to fetch initial value if one wants to use it for SSR.
commented

Thanks, that makes sense.

To clarify on your last point:

If I would want to use this cookie server-side, it would be to allow for data in the store to be used for SSR, in which case the implementation in the prototype doesn't solve this, as it can't read the cookies from the incoming request

The proposed change would support reading cookies from the incoming request. It accomplishes this by using a server-side hook to extract the cookies from the incoming request.

See: https://github.com/joshnuss/sk-cookie-store-experiment/blob/main/src/hooks.server.js

commented

Oh damn, that's smart! I missed that part of your prototype. On the one hand, I usually don't like this, as it "hides" the event flow from the user and adds a few more moving parts, but on the other hand, it feels like a very svelty way of doing things, and I DX wise, this seems to me as the right move. The only concern I have are the following:

  • Is there a possibility of the store getting initiated, and the server then reading the response, leaving the cookie without the cookie value as the server-side storage isn't re-actively linked to the store?
  • This would make this library a SvelteKit only project. Personally I think this is a reasonable compromise, as most people build Svelte projects with Kit, but if you disagree, it would of course be possible to integrate a cookie store that only works client side or from load functions into the project, and then built an extension that works natively with SvelteKit.

Do you want to have a go at this, or should I write a PR?

commented

Is there a possibility of the store getting initiated, and the server then reading the response, leaving the cookie without the cookie value as the server-side storage isn't re-actively linked to the store?

Not sure, but it's a good point about consistency between the store and request. Would have to test it.
Also, what happens if a handler writes a new cookie value, will the store be updated?

This would make this library a SvelteKit only project.

I think it could be built in a way that it doesn't depend on SvelteKit. The hooks part would be optional. People not using SvelteKit wouldn't import it and it would be tree-shaken.

Do you want to have a go at this, or should I write a PR?

If you have time, feel free to open a PR!

commented

I ended up never finishing this, see #213 for explanation.