Angular Strategy Pattern, using DI, at component/service level not module (Local, Session storage)

Question

I store data in both browser's Local and Session storage. What is a good design practice for implementing Local and Session Storage services? I have a generic service for handling json.

@Injectable()
export class StorageService {
    private storage: any;

    constructor() {
        this.storage = sessionStorage;
    }

    public retrieve(key: string): any {
        const item = this.storage.getItem(key);

        if (item && item !== 'undefined') {
            return JSON.parse(this.storage.getItem(key));
        }

        return;
    }

    public store(key: string, value: any) {
        this.storage.setItem(key, JSON.stringify(value));
    }

    public remove(key: string) {
        this.storage.removeItem(key);
    }
}

As you can see, currently its working with Session. I need to handle also Local.

1. I can make an abstract parent class with these functions and in children provide the Local or Session instance: LocalService, SessionService -> StorageService.
2. I can add a parameter to these json functions in order to know which storage I use.

public removeLocal() { .. }
public removeSession() { .. }

private remove(key: string, storage: Storage) {
    storage.removeItem(key);
}

3. If you have any other better idea, please let me know. At this moment, I prefer variant 1 but I'm open to everything.

Answer 1

Expanding the answer of @StepUp after trial and error research. https://stackoverflow.com/a/73643938/9442199
Use case: I want Local Storage Service in one component.ts and in another my-service.ts the Sesssion Storage Service. Also, rename export interface Storage to IStorage. Because there is confusion between library and our own.

Please check this Stackblitz example to see the concrete implementation.

Problem 1 - a lot of manual instantiation

service or component.ts

constructor() {
    const storageFactory = new StorageFactory();
    const storage = new StorageService(storageFactory.getInstanceByKey('local'))
    storage.store('some key', 'some value')
}

I have to instantiate these classes in all the constructors where I need a browser storage. This should not be the case since Angular has DI which can give me only one instance. If I have 10 components I need to write those lines in each of them.

We will start from the bottom.

Angular DI Strategy Pattern with InjectionTokens

So, all web tutorials use an obsolete version of private injector: Injector without InjectionTokens. I have found a way. This is how Strategy Pattern is implemented in Angular.

shared.module.ts

{
    provide: LOCAL, // the injection token (~string identifier)
    useClass: LocalStorage
},
{
    provide: SESSION,
    useClass: SessionStorage
},

storage-token.ts

// Tokens work as an abstract factory provider. Specific services linked to a string key in SharedModule.
export const LOCAL = new InjectionToken<string>('LOCAL');
export const SESSION = new InjectionToken<string>('SESSION');

your-class.service.ts

constructor(
@Inject(LOCAL) private localStorageService: IStorage, //The IStrategy
OR
@Inject(SESSION) private sessionStorageService: IStorage,
)

Where needed, import SharedModule and in the component/service import storage-token.ts and istorage.ts.

Problem 2 - no factory

Maybe we want to implement some customization before giving the LocalStorage class. The factory is created by the providers:[] of Angular with token identifiers. See factory in @StepUp answer.

shared.module.ts

{
    provide: LOCAL,
    useFactory: () => {
        return new StorageFactory().getInstanceByKey('local');
    }
},
{
    provide: SESSION,
    useFactory: () => {
        return new StorageFactory().getInstanceByKey('session');
    }
},

Problem 3 - duplicate code in local and session services

The next problem is that we have duplicate code in local and session ~ some json stringify upon retrieve and set item. Using @StepUp's service.

shared.module.ts

{
    provide: LOCAL,
    useFactory: () => {
        return new StorageService(new StorageFactory().getInstanceByKey('local'));
    }
},
{
    provide: SESSION,
    useFactory: () => {
        return new StorageService(new StorageFactory().getInstanceByKey('session'));
    }
},

@Inject(LOCAL) private localStorageService: StorageService,
@Inject(SESSION) private sessionStorageService: StorageService,

Problem 4 - this seems over engineered

Instead of new StorageService(IStorage) you can use Template Design Pattern and have them inherit from an abstract class: LocalStorage extends StorageService where you put the repetitive code.

StorageService.ts

abstract getItem();

retrieve() {
    const res = this.getItem();
    // json stringify or additional manipulation
    return res;
}

And return to having only: module.ts

useFactory: () => { return new StorageFactory().getInstanceByKey('local'); }

Alternative solution

This guide is offering a very well structured solution for Strategy Pattern: Local, Session, Cookies storage. But he is choosing which service at the module level. If you have two components in the same module how do you choose Local for one and Session for the other? I don't see the use of this method. I paste it, because the classes are very nicely packed and respect a good design.

https://medium.com/monstar-lab-bangladesh-engineering/making-configurable-angular-feature-modules-using-strategy-pattern-b8f43340550a

SO question arriving at the same problem

Strategy Pattern with Angular and Typescript

Answer 2

This is a place where Strategy pattern can be used:

Strategy pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

Let me show an example.

We need to have some common behaviour that will be shared across all strategies. In our case, it would be CRUD methods of session or local storages:

export interface Storage {    
    retrieve(key: string): string | null ;

    store(key: string, value: string): void;

    remove(key: string): void;
}

And its concrete implementations. These are exchangeable strategies:

export class LocalStorage implements Storage {

    retrieve(key: string): string | null {
        return localStorage.getItem(key)
    }

    store(key: string, value: string): void {
        localStorage.setItem(key, value);
    }

    remove(key: string): void {
        localStorage.removeItem(key);
    }
}

export class SessionStorage implements Storage {

    retrieve(key: string): string | null {
        return sessionStorage.getItem(key)
    }

    store(key: string, value: string): void {
        sessionStorage.setItem(key, value);
    }

    remove(key: string): void {
        sessionStorage.removeItem(key);
    }
}

This is a class which will execute strategies:

export class StorageService {
    public storage: Storage;

    constructor(storage: Storage) {
        this.storage = storage;
    }

    retrieve(key: string): string | null {
        return this.storage.retrieve(key)
    }

    store(key: string, value: string): void {
        this.storage.store(key, value);
    }

    remove(key: string): void {
        this.storage.remove(key);
    }
}

And then we can call our strategies like this:

const storage = new StorageService(new LocalStorage())
storage.store('some key', 'some value')

This design is compliant with the open/closed principle. So if you would need to add other storages, then:

• you would add new class with new strategy
• you will not edit StorageService class

And it is compliant with open closed principle.

UPDATE:

Thank for comment to Wiktor Zychla:

The client still has to decide directly which storage is passed to the storage service. Everytime the client needs the storage service, it has to pass a specific implementation: new StorageService(new LocalStorage()). A step forward would be to hide the new LocalStorage() behind a factory new LocalStorageFactory().Create() so that the API call is fixed but the factory can be reconfigured somewhere, e.g. depending on the configuration.

Yeah, it is really true. So we need a place where all strategies can be stored. And we should be able to get necessary strategy from this store. So this is a place where simple factory can be used. Simple factory is not Factory method pattern and not Abstract factory.

export class StorageFactory {
    #storagesByKey : Record<string, Storage> = {
        'local': new LocalStorage(),
        'session': new SessionStorage(),
    }

    getInstanceByKey(key: string) {
        return this.#storagesByKey[key];
    }
}

and then you can get instance of desired storage easier:

const storageFactory = new StorageFactory();
const storage = new StorageService(storageFactory.getInstanceByKey('local'))
storage.store('some key', 'some value')

UPDATE 1

Can you show me how would this be implemented in Angular? Which one is Injectable(), and how do I use one service in a component ngOnInit for example?

It looks like strategies should be injectable. There is a good post about how you can apply strategy pattern in Angluar 2+.

And its stackblitz example can be seen here.

Answer 3

I would not use a service for this. It can be a simple class suited to every usage.

class MyStorage {
    constructor(
        private storage: Storage,
        private readonly prefix = '',
    ) {}

    private createKey(key: string): string {
        return this.prefix ? `${this.prefix}-${key}` : key;
    }

    public retrieve<T = any>(key: string): T {
        const item = this.storage.getItem(this.createKey(key));

        try {
            if (item && item !== 'undefined') {
                return JSON.parse(item);
            }
        } catch { }

        return;
    }

    public store<T = any>(key: string, value: T): void {
        this.storage.setItem(this.createKey(key), JSON.stringify(value));
    }

    public remove(key: string): void {
        this.storage.removeItem(this.createKey(key));
    }
}

The main selling points of this are:

• prefix - later, when you would use this multiple times at different places, the prefix will make sure you don't have name collisions.
• The generics are a sort of safeguard as you can use them to validate the assigned value.

export const userSettingsSotrage = new MyStorage(localStorage, '[USER]');

userSettingsSotrage.retrieve<User>('user'); // Just a shorthand for "as User"
userSettingsSotrage.store<User>('user', userOrUndefined); // Error
userSettingsSotrage.store<User>('user', user); // OK

---

If you wanted more type safety, you could give the whole MyStorage generics to define keys that exist and their types. You could even do so in a manner that would parse the value into a specific class that you want on a key basis.