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

Make private properties more private and harder to use #1083

Merged
merged 1 commit into from
Aug 20, 2017

Conversation

lelandrichardson
Copy link
Collaborator

to: @ljharb @aweary

This is in preparation for Enzyme v3.0. We are moving properties that are considered private and implementation details to use symbols and harder to rely on property names in an effort to make future migrations easier.

Copy link
Collaborator

@aweary aweary left a comment

Choose a reason for hiding this comment

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

LGTM, with a small typo fix. Makes sense to me.

get() {
throw new Error(`
Attempted to access ShallowWrapper::${prop}, which was previously a private property on
Enzyme ShallowWrapper instances, but is no longer and should not be relied upon.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Need to change ShallowWrapper to ReactWrapper.

@lelandrichardson lelandrichardson merged commit 0edf10f into master Aug 20, 2017
@lelandrichardson lelandrichardson deleted the lmr--move-to-private-props branch August 20, 2017 20:03
@ljharb
Copy link
Member

ljharb commented Aug 20, 2017

It'd be cool if we could go a bit slower on merging these things; it's Sunday and cell reception is limited on my drive home from out of town.

@lelandrichardson
Copy link
Collaborator Author

@ljharb i'll slow down... i'm trying to take advantage of time when i have it though, and some of these PRs are hard to do in parallel.

@ljharb
Copy link
Member

ljharb commented Aug 21, 2017

PRs don't have to block proceeding on multiple local branches, and rebasing/PRing as things are merged :-)

@@ -4300,14 +4300,14 @@ describe('shallow', () => {
it('works with a name', () => {
const wrapper = shallow(<div />);
wrapper.single('foo', (node) => {
expect(node).to.equal(wrapper.node);
expect(node).to.equal(wrapper[sym('__node__')]);
Copy link
Member

Choose a reason for hiding this comment

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

Can these underscores be added by the sym function, instead of hardcoded in the text?

@@ -1060,4 +1071,25 @@ if (ITERATOR_SYMBOL) {
});
}

function privateWarning(prop, extraMessage) {
Copy link
Member

Choose a reason for hiding this comment

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

this function seems like it could live in a separate file and be shared, and take the proto as an argument?

@@ -362,3 +362,15 @@ export function displayNameOfNode(node) {

return type.displayName || (typeof type === 'function' ? functionName(type) : type.name || type);
}

export function sym(s) {
return typeof Symbol === 'function' ? Symbol.for(`enzyme.${s}`) : s;
Copy link
Member

Choose a reason for hiding this comment

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

the presence of Symbol doesn't ensure Symbol.for is present - this should maybe be a fallback from Symbol.for to a memoized Symbol to `___${s}___`?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

can you explain what you're proposing a little bit more? i'm not sure I understand

Copy link
Member

Choose a reason for hiding this comment

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

const syms = {};
function sym(s) {
  const k = `enzyme.___${s}___`;
  if (typeof Symbol === 'function') {
    if (typeof Symbol.for === 'function') return Symbol.for(k);
    const sym = Symbol(k);
    syms[s] = sym;
    return sym;
  }
  return k;
}

}

export function privateSet(obj, prop, value) {
Object.defineProperty(obj, prop, {
Copy link
Member

Choose a reason for hiding this comment

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

any reason not to use a privateGet as well, so it could later be refactored to use WeakMaps?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no real reason, no. It would add some syntactic overhead relative to obj[prop], but i'm not opposed to it if we want to. I figured we'd just keep this setup until private properties are at whatever stage makes you comfortable with us using them :)

Copy link
Member

Choose a reason for hiding this comment

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

that's exactly why i want them to use WeakMap, because that's how private properties will be transpiled :-)

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.

3 participants