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

Fix .clear() behavior #136

Merged
merged 2 commits into from
Jan 7, 2021
Merged

Fix .clear() behavior #136

merged 2 commits into from
Jan 7, 2021

Conversation

sindresorhus
Copy link
Owner

Fixes #135

Copy link

@willium willium left a comment

Choose a reason for hiding this comment

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

Awesome to see!

source/index.ts Outdated
*/
clear(): void {
const keys = Object.keys(this.store);
Copy link

Choose a reason for hiding this comment

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

If the current value of the store has a key deleted that is in the defaults or schema, I believe it wouldn't be included in this and you'd end up with an incomplete default.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Good catch: 8b1ee0b


for (const key of keys) {
this.reset(key);
}
Copy link

Choose a reason for hiding this comment

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

I think it'd make sense to emit the change event here, what do you think?

this.events.emit('change');

Copy link
Owner Author

Choose a reason for hiding this comment

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

That is already done, since we set this.store:

this.events.emit('change');

Copy link

Choose a reason for hiding this comment

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

@sindresorhus this is actually causing a regressive bug in my program. While we set this.store, we do it before reseting the parameters, and we set it to a blank object—which disobeys the type contract. Subsequently it's emitting an onDidAnyChange event where the current value is undefined (which disobeys the type guarantees for the store, given defaults)

Copy link

Choose a reason for hiding this comment

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

this doesn't cause a static typing violation because of the use Partial in several places where I don't believe it makes sense. Ideally it'd be possible to create a Conf with strict type guarantee. The type of details should statically guaranteed to be the base type.

Copy link
Owner Author

Choose a reason for hiding this comment

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

I don't have the time to look into this right now, so it would be good if you could open an issue instead. Even better if you could also submit some failing tests.

Copy link

Choose a reason for hiding this comment

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

I created an issue. The type safety bug here is pretty important. The clear() bug is as well, given that is breaks the contract with the client regarding types.

@willium
Copy link

willium commented Jan 7, 2021

excited to see this land! only remaining concern is that this is probably a breaking change for people who rely on clear() to wipe the slate, ignoring defaults. It's your library, so up to you on how to handle that. If you want to keep it graceful, you could change the method signature to something like

public clear(restoreDefaults?: boolean): void

so that people like me can just pass true and current users won't notice any change

@sindresorhus
Copy link
Owner Author

It's really just a bug fix, but I will do a major release just to be careful.

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.

reset without arguments (keys)
2 participants