polemius/recoil-persist

Support arbitrary storages?

bebraw opened this issue · 10 comments

bebraw commented

I'm thinking of doing something along what you are doing but with IndexedDB. Given that API is asynchronous, it looks like the API of recoil-persist would have to change a little bit to accommodate this. Would you be open for a PR?

The other part of this for me is subscribing to changes from IndexedDB as third parties can change the data but my feeling is that it's something that can be solved outside of recoil-persist and on Recoil side.

polemius commented

Would you be open for a PR?

Of course! Feel free to send PR

bebraw commented
mbret commented

@bebraw I am using this code to deal with my indexeddb and async initial state. This can give you some idea of implementation https://gist.github.com/mbret/2aa38e9bfa60d1a13d30f3a8e4f336d3

bebraw commented

@mbret Cool. In my use case it first went to a Recoil effect and then it became a wrapper for an Observable.

The rough pattern is something like this:

const observableEffect = ({ setSelf }) => {
  const observer = {
    next(num) {
      console.log("number", num);
      setSelf(num);
    },
    error(err) {
      console.error("error: " + err);
    },
    complete() {
      console.log("complete");
    },
  };

  let o$;

  run().then((observable) => {
    o$ = observable.values();
    o$.subscribe(observer);
  });

  return () => o$?.unsubscribe();
};

// ...

const countState = atom({
  key: "countState",
  default: 0,
  effects_UNSTABLE: [observableEffect],
});

Likely you'll need to adjust it if you go this way. In my case, the use of IndexedDB is hidden behind the facade.

Above is why I was asking if recoil-persist is needed anymore as recoil seems to cover the need once the API gets stable. 😄

mbret commented

At first I was looking for packages as well and then I realize recoil already offer pretty much all we need to get it working quickly indeed.

I imagine this library could be updated later once the library is not experimental anymore into the redux-persis of recoil. I mean the guy already took the name recoil-persist haha. I would be very glad to contribute to it.

As per your solution, I feel like this is much better to use atom effect indeed. I might want to try it as well and compare both solution. It does answer the problem of dynamic atom (Although I am not using it). Very interesting

bebraw commented

I imagine this library could be updated later once the library is not experimental anymore into the redux-persis of recoil. I mean the guy already took the name recoil-persist haha. I would be very glad to contribute to it.

Yup, that's a good point.

As per your solution, I feel like this is much better to use atom effect indeed. I might want to try it as well and compare both solution. It does answer the problem of dynamic atom (Although I am not using it). Very interesting

Yeah, this is pretty much how you can marry recoil with an observable system (rxjs or any other). Technically you can replace recoil with rxjs to some extent but that's another story. 😄

mbret commented

Technically you can replace recoil with rxjs to some extent

Yeah but the whole point of recoil is to be coupled with React so you might end up doing a recoil with rxjs under the hood ^^

bebraw commented

Yeah but the whole point of recoil is to be coupled with React so you might end up doing a recoil with rxjs under the hood ^^

Exactly. That's why recoil feels like the right place where to connect with streams of data as it's optimized for React.

I guess we'll leave the issue here for now until the author comments on what to do with the effects. The most likely option is that we'll wait for recoil to stabilize the API first as discussed earlier. 😎

rhys-saldanha commented

v2 of this repo now uses recoil effects, I'd recommend giving it a read for inspiration on how to use arbitrary storages with recoil.

bebraw commented

Cool. Let's close this one?

  • 👍2