Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: always use localStorage if no settingsApi #603

Merged
merged 2 commits into from
Dec 7, 2023

Conversation

artemmufazalov
Copy link
Member

If no settingsApi is provided, app should always use localStorage

window.api.postSetting(name, value);
} else {
localStorage.setItem(name, value);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially this operation may fail, sp lets wrap it with try ... catch.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should be in catch section in this case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be just catch {}.

@@ -3,8 +3,11 @@ import {getValueFromLS} from './utils';
export const userSettings = window.userSettings || {};
export const systemSettings = window.systemSettings || {};

export const settingsApi = window.web_version ? systemSettings.settingsApi : undefined;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we define settingsApi ourselves if it isn't defined initially? We know methods it should provide and can define it. Thus in other code there will be no need to worry, just use settingsApi.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please clarify you question? I didn't get it

If you mean changing settingsApi on a go, this case isn't supported. The problem is that when we declare new settingsApi by ourselves, all currently stored settings should be copied there. Otherwise, there will be scenario, where our settings partly stored in localStorage, partly in other store, it will be a mess.

If you mean incapsulating this logic into some instance, that will provide certain API and decide where to store data within itself, I don't think it's really needed. The problem, that I solve here, is that we want to use localStorage both in internal and in embedded version. Now it will be a migration period, after which settingsApi will be deleted

Currently, it's first iteration to allow UI usage in Nebius, where there is no special backend service for user settings. After that I add some migration to code, that will copy data from settingsApi to localStorage. And as final step, use only localStorage

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've got it! Lets stick to current version!

@artemmufazalov artemmufazalov merged commit ff692df into main Dec 7, 2023
4 checks passed
@artemmufazalov artemmufazalov deleted the settings-use-ls-by-default branch December 7, 2023 11:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants