Skip to content

Replace object getter with Object.defineProperty in TestRenderer#10473

Merged
flarnie merged 4 commits intofacebook:masterfrom
flarnie:addTransformForObjectGetters
Aug 17, 2017
Merged

Replace object getter with Object.defineProperty in TestRenderer#10473
flarnie merged 4 commits intofacebook:masterfrom
flarnie:addTransformForObjectGetters

Conversation

@flarnie
Copy link
Contributor

@flarnie flarnie commented Aug 16, 2017

what is the change?:
Replaces an Object Getter 1 with Object.defineProperty.

why make this change?:
Our internal build system does not support object getters.

test plan:
We should do follow-up work to ensure that this doesn't come up again -
we can't commit code which uses object getters.

issue:
No issue opened yet

**what is the change?:**
We were not transforming object getters[1], and our new TestRenderer
uses one.[2]

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get
[2]: https://github.com/facebook/react/blob/master/src/renderers/testing/ReactTestRendererFiberEntry.js#L569

**why make this change?:**
Our internal build system was not supporting object getters.

**test plan:**
`yarn build && yarn test`
Also built and opened the 'packaging' fixture.

Honestly I'm not sure what else to test, this seems pretty low risk.

**issue:**
None opened yet
@flarnie flarnie added this to the 16.0 milestone Aug 16, 2017
@sebmarkbage
Copy link
Contributor

We have tried to avoid transforms that potentially add a lot of code because it will lead to unexpectedly slow code and larger file sizes. I think this might be one right?

I'd prefer to check in the changed code.

@flarnie
Copy link
Contributor Author

flarnie commented Aug 16, 2017

Sure thing - will check in the changed code.

We should come up with some other way of making sure this doesn't happen again - still have not figured out how I could have checked that this syntax was not supported.

We could either add a lint or something on our side, or discover a new step for testing when syncing.

@bvaughn
Copy link
Contributor

bvaughn commented Aug 16, 2017

Why would we need this transform or code-change? Getters for non-computed props are well-supported (IE9+).

Edit: Sorry. I saw this PR before I saw your comment about Haste in the group chat.

**what is the change?:**
Replaces an Object Getter [1] with `Object.defineProperty`.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get

**why make this change?:**
Our internal build system does not support object getters.

**test plan:**
We should do follow-up work to ensure that this doesn't come up again -
we can't commit code which uses object getters.

**issue:**
No issue opened yet
@flarnie flarnie changed the title Add babel transform for object getters Replace object getter with Object.defineProperty in TestRenderer Aug 16, 2017
return wrapFiber(root.current.child);
},
enumerable: true,
configurable: true,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm curious- why does this need to be enumerable or configurable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was copying what the babel transform would do - seems like a reasonable default. They would both default to false otherwise.

Since it's not _root, it seems like it should be enumerable and configurable.

Copy link
Contributor

Choose a reason for hiding this comment

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

enumerable perhaps but I don't think it should be configurable. (Both of these default to false by the way, which I think would also be reasonable in this case.) 😄 Not a big deal though just sharing my thoughts

Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty much every property we have is enumerable and configurable since that's the default for assignment and object literal construction. So why should this property be different? The reason configurable is useful is that it allows for patching, polyfilling and backward compatibility fixes. The downside is that it might allow for bad patching, polyfilling etc. :)

Copy link
Contributor

Choose a reason for hiding this comment

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

It felt weird for a getter that might throw to be enumerable. I don't hold this opinion strongly though. 😄

**what is the change?:**
- switched from `Object.defineProperties` to `Object.defineProperty`
- set some undefined properties to get flow to pass

**why make this change?:**
- Flow doesn't seem to play nicely with `Object.defineProperty/ies`
  calls, specifically when you implement `get` and `set` methods.
  See facebook/flow#1336
- Switched from `properties` to `property` because it seems more
  conventional in our codebase to use `property`, and I'm only setting
  one anyway.

**test plan:**
`flow`

**issue:**
no issue
@flarnie
Copy link
Contributor Author

flarnie commented Aug 16, 2017

Updated things a bit because:

  • Flow doesn't seem to play nicely with Object.defineProperty/ies
    calls, specifically when you implement get and set methods.
    See Object.defineProperty() getters do not typecheck flow#1336
  • Switched from properties to property because it seems more
    conventional in our codebase to use property, and I'm only setting
    one anyway.

**what is the change?:**
Forced the typing of an argument to 'Object.defineProperty' to be
'Object' to avoid an issue with Flow.

**why make this change?:**
To get tests passing and flow passing.

**test plan:**
`flow && yarn test`

**issue:**
@flarnie flarnie merged commit 149860b into facebook:master Aug 17, 2017
@flarnie flarnie deleted the addTransformForObjectGetters branch May 25, 2018 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants