fix(persist-state): implementation of StateStorage should work with c…

[stLmpp]

…lass instances

Since we were using destructuring to get the methods "getItem" and "setItem",
if this were used we would get an undefined error, because this is undefined.
This change simply removes the destructuring of the methods

This would not work:

import { createStore, withProps } from '@ngneat/elf';
import { persistState, StateStorage } from '@ngneat/elf-persist-state';

class CustomStateStorage implements StateStorage {
  private readonly _storage: Record<string, string> = {};

  getItem<T extends Record<string, any>>(
    key: string
  ): Async<T | undefined> {
    const value = this._storage[key];
    return Promise.resolve(value && JSON.parse(value));
  }

  removeItem(key: string): Async<boolean> {
    delete this._storage[key];
    return Promise.resolve(true);
  }

  setItem(key: string, value: Record<string, any>): Async<boolean> {
    this._storage[key] = JSON.stringify(value);
    return Promise.resolve(true);
  }
}

const customStateStorage = new CustomStateStorage();

const store = createStore(
  { name: 'store' },
  withProps<{ id: number; }>({ id: 1 }),
);
persistState(store, {
  storage: customStateStorage,
});

It would throw an error:

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngneat/elf/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

StateStorage class instances does not work when using this

What is the new behavior?

StateStorage class instances works when using this

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

There were workarounds for this, using arrow function in the class methods or binding the methods to this in the constructor of the class should work fine, but I think this fix is valid