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

Provide way to omit __interal__ from store on get #137

Closed
wants to merge 1 commit into from

Conversation

willium
Copy link

@willium willium commented Jan 11, 2021

The internal key causes some problems, both during write (#114) and at read (can't trust MyStore.keys() or MyStore.values() without omitting internal). We should at least export the variable so the client can manually omit it (and at best, provide a more ergonomic pattern—perhaps a WeakMap?)

The internal key causes some problems, both during write (sindresorhus#114) and at read (can't trust MyStore.keys() or MyStore.values() without omitting __internal__). We should at least export the variable so the client can manually omit it (and at best, provide a more ergonomic pattern—perhaps a WeakMap?)
@willium
Copy link
Author

willium commented Jan 11, 2021

In my subclass, I do this:

	public get current(): T {
		return omit(this.store, "__internal__") as T
	}

	public set current(value: T) {
		const { __internal__ } = this.store
		this.store = {...value, __internal__ } as T
	}

which seems to work but isn't ideal (and at the very least, I'd love import INTERNAL_KEY rather than hardcode it here).

@sindresorhus
Copy link
Owner

I'm not interested in exposing internal implementation details. This should be properly fixed by making changes to this.store not change __internal__. This can be done by making this.store be a facade for an internal this._store and have this.store be getter/setters that handles ignoring __internal__.

@sindresorhus
Copy link
Owner

(and at best, provide a more ergonomic pattern—perhaps a WeakMap?)

Cannot use WeakMap as the __internal__ key needs to be persisted.

@willium
Copy link
Author

willium commented Jan 11, 2021

fair enough. do you think the changes to the getter/setter goes beyond what I did in my subclass?

@sindresorhus
Copy link
Owner

I think that should be enough as this.store is used for any reading/writing.

@willium
Copy link
Author

willium commented Jan 11, 2021

should I submit a PR with this change?

@sindresorhus
Copy link
Owner

Yes, that would be great. Needs some tests too.

@willium
Copy link
Author

willium commented Jan 11, 2021

It's unfortunately not going to be super simple as migrations (or at least their tests) rely on being able to lookup migrations by the internal property (for example this, relies on .get() which in turn uses .store). I'm not sure your preferred strategy for exposing/mocking private methods for tests, but if you're willing to remove the ability to .get() data off the internal key, we could introduce some kind of method _getInternal() that doesn't use .get store, though in order to use it in the tests it'd have to be public...

@willium
Copy link
Author

willium commented Jan 11, 2021

We could also do some any hacking in the tests

@sindresorhus
Copy link
Owner

we could introduce some kind of method _getInternal() that doesn't use .get store, though in order to use it in the tests it'd have to be public...

Sounds good. We can make it public only when if (process.env.NODE_ENV === 'test') {.

Base automatically changed from master to main January 23, 2021 08:51
@sindresorhus
Copy link
Owner

Friendly bump :)

@sindresorhus
Copy link
Owner

Closing for lack of activity.

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.

None yet

2 participants