Skip to content

Reduce lifecycle hooks and use of private methods#3

Open
felthy wants to merge 1 commit intomasterfrom
feature/no-componentdidupdate
Open

Reduce lifecycle hooks and use of private methods#3
felthy wants to merge 1 commit intomasterfrom
feature/no-componentdidupdate

Conversation

@felthy
Copy link
Copy Markdown
Member

@felthy felthy commented Jul 18, 2018

The componentDidUpdate() lifecycle method was only needed to work around a TypeError: Cannot read property 'detach' of undefined being thrown when a dynamic sheet is added via HMR.

This PR removes componentDidUpdate() and does all its work in componentWillReceiveProps() instead, so it won’t be able to be merged until react-jss stops attempting to detach the nonexistent previous dynamic sheet.

I also removed the call to createState() and instead restore the state that was created in the constructor. One fewer private method being called and it fixes the actual problem more directly.

@felthy
Copy link
Copy Markdown
Member Author

felthy commented Jul 18, 2018

Relies on cssinjs/react-jss#281

Comment thread src/injectSheet.js
// This will never be called during hot module replacement, so we can use it as a place to
// store away the SheetManager
super.componentWillMount()
managers.set(Object.getPrototypeOf(this), this.manager)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Can't this also be in the constructor? Or is the constructor when on HMR?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

No because the this in the constructor is not the proxy.
However I had a read of Redux’ connectAdvanced() that you referred to before and if I use their idea - a counter (version) - as the key then I could move this into the constructor.

I was thinking there wasn’t much reason to switch to the version idea because we need to track the SheetsManager anyway, but moving this code to the constructor might be a good enough reason. What do you think?

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