Skip to content

feat(store/currentLang): enable persistant storage #1582

@rbalet

Description

@rbalet

Current behavior

Actually, when we do change the app language, and reload the page, the currentLang is lost and we start all over again.

Expected behavior

Being able, if wished, to keep the currentLang even after reload.

What is the motivation / use case for changing the behavior?

  1. Opt-in for his first version, this would be just a real nice addition to the library.
  2. A lot of people are creating their own service just to deal with this. (Pretty sure every Ionic/Angular users in the fact)
  3. People doing there own things is sub-optimal, as
    a. The library instantiate first -> fetch the default lang
    b. The user instantiate his own service -> get the stored langage -> set this as being the used one
    c. This trigger a new fetch for the new set of language -> AKA one useless request being sent.

How do you think that we should implement this?

  1. A new config
storage?:  {
   type: 'localStorage' | 'sessionStorage'
   key?: 'CURRENT_LANG' | string
}
  1. Type
    The type let you select if you wish to have it saved inside the local or session storage.
    Note: if wished and later down the road, other, more persistent storage type could be implemented

  2. Key
    I would default to CURRENT_LANG or something that is meaningful to the whom is reading the storage information

  3. Change in the lang / fallbackLang logic
    Note: can/should be done in a separate issue as it has some implication & require langs to be implemented.
    If no lang has been added to the config, I would use
    a. The storage if the config exists
    b. The browserLang if the value is found inside the langs array
    c. The fallback if the config exists.
    d. The first langs[0]if the config exists

Therefore, if lang is provided, this would override the storage information.

Afterthought. (Test to be added)

such implementation will enable

  1. semi persistent storage
  2. The use of different storage in case of lazy loaded - library usage
  3. The use of the same storage/lang across external libraries.
  4. The use of lang to override the storage logic

Doc update

Even if this issue is not adding any breaking change, I would propose to update the doc, as a new more easy way will be enable for user to use an even more powerful library.

  1. You provide the langs, the storage, and you're free to go.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions