stop calling repository.didUpdate when commit message changes.
#1464
Conversation
negated assertions ftw
| @@ -87,6 +87,16 @@ describe('CommitController', function() { | |||
| assert.strictEqual(wrapper.find('CommitView').prop('message'), 'some message'); | |||
| }); | |||
|
|
|||
| it('repository.didUpdate is not called when commit message changes', function() { | |||
There was a problem hiding this comment.
This is very minor, but it looks like all of the surrounding tests' descriptions are phrased so that they sound right after the word "it". I'd maybe tweak the description to say something like
it("does not cause the repository to update").
| this.commitMessage = message; | ||
| if (oldMessage !== message) { | ||
| this.didUpdate(); | ||
| } |
There was a problem hiding this comment.
Oh, interesting. Changing the message triggered an update, and therefore at least a partial re-render of the React tree, so that UI elements that change state based on the message's length and presence have a chance to be updated. Specifically I'm thinking of:
- The enablement of the "Commit" button; it should be disabled if the message is empty; and
- The "remaining characters" counter that changes as you type the subject line;
But, the way the commit message is handled has been shuffled a lot with the introduction of the AtomTextEditor wrapper component and various refactorings, so I'm not 100% sure that these things won't be updated by something else.
Can you confirm that those didn't break? If they still work, then we definitely should take this out because it's not needed. If they don't, an alternate approach would be to fuss with either the UserStore or the GitTabController to fine-tune when loadUsersFromLocalRepo is invoked. We should only really need to re-call it when something has changed that would change the available co-authors, like a fetch or a commit.
There was a problem hiding this comment.
Looking a little more closely at @maxbrunsfeld's flame graph, one thing that stands out to me is that we're calling setState() and running an entire render cycle every time loadUsersFromLocalRepo finishes, even though the result is the same. I'm guessing that's the setState call in here:
github/lib/controllers/git-tab-controller.js
Lines 69 to 74 in df5ef8c
Maybe we should also prevent UserStore.onDidUpdate() from firing when the user list hasn't actually changed... ?
There was a problem hiding this comment.
@smashwilson yes, my original solution was for the UserStore to not invoke loadUsersFromLocalRepo when not needed.
However, I noticed we were also performing a bunch of other unnecessary operations on the repository when the commit message was updated (, and figured it would be a better performance improvement to fix the problem here instead of in the user store.
I did some additional testing and confirmed that the commit button is still disabled if the message is empty, and the remaining characters counter changes as you type in the commit box. Which makes sense, because the CommitView component has its own logic for dealing with commit message updates, that forces a re render when the message has changed.
There was a problem hiding this comment.
Which makes sense, because the CommitView component has its own logic for dealing with commit message updates, that forces a re render when the message has changed.
✨ This was the piece that I wasn't sure was in place or not. Excellent 🍰
There was a problem hiding this comment.
great, thanks @smashwilson !
We are performing a bunch of unnecessary operations when the commit message changes. It's causing some slowness.
See #1463 for details.
As far as I can tell, updating the repository when the commit message changes may have been necessary at some point in the past (like for the old way amending used to work, perhaps?) But it doesn't seem to be useful now. Nevertheless, it's important to test carefully here to make sure removing this won't cause any surprise regressions.
Test Plan
manually tested the following flows:
unit tests