Skip to content
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.

Refactor Pending Breakpoints to fix reloading #2877

Merged
merged 11 commits into from
May 15, 2017

Conversation

jasonLaster
Copy link
Contributor

Associated Issue: #2817

Summary of Changes

  • Refactor how pending breakpoints are stored and updated in the reducer
  • add lots of tests
  • update checkPendingBreakpoints


for (const source in filteredSources) {
await dispatch(newSource(source));
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we need to update this before we merge!

@codehag codehag changed the title Refactor Pending Breakpoints to fix reloading [WIP] Refactor Pending Breakpoints to fix reloading May 12, 2017
Copy link
Contributor

@codehag codehag left a comment

Choose a reason for hiding this comment

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

Some comments, let me know if there are any questions! Great refactor!

const bp = getBreakpoint(state, location);

if (sameSource && !bp) {
if (location.column && isEnabled("columnBreakpoints")) {
Copy link
Contributor

Choose a reason for hiding this comment

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

As mentioned earlier, this block probably needs to be refactored. The if statements do not make sense, as in all cases we will call await dispatch(addBreakpoint(location, { condition }));. Instead we probably want to use an early return if !isEnabled("columnBreakpoints").

}
});
const pendingBreakpointsList = pendingBreakpoints.valueSeq().toJS();
for (let pendingBreakpoint of pendingBreakpointsList) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Great!

}
}
});
const pendingBreakpointsList = pendingBreakpoints.valueSeq().toJS();
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: list has a lot of different connotations. for more precision could we perhaps call it pendingBreakpointsArray? I think it might be more meaningful to newcomers

await dispatch(actions.addBreakpoint({ sourceId: "a", line: 5 }));
await dispatch(actions.addBreakpoint({ sourceId: "b", line: 6 }));
it("when the user adds a sliding breakpoint, a corresponding pending breakpoint should be added", async () => {
const { dispatch, getState } = createStore(slidingMockThreadClient);
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: I think it might be easy to break this, by not getting the right offset between slidingMockThreadClient and slidLocation. We can explicitly associate these two (or more) stub elements by using a wrapper function. Here is an example of how it might be done:

function generateMockThreadClient (offset = 0) {
  return { 
    setBreakpoint: (location, condition) => {
      return new Promise((resolve, reject) => {
        const actualLocation = Object.assign({}, location, {
          line: location.line + offset
        });
        resolve({ id: makeLocationId(location), actualLocation, condition });
      });
    }
  };
};

function generateOffsetThreadClient(offset, location) => {
  const slidingMockThreadClient = generateSlidingMockThreadClient(offset);
  const slidLocation = Object.assign({}, location, { line: location.line + offset });
  return { slidingMockThreadClient, slidLocation };
}

function ... () { // wherever this will be used
  const location = { sourceId: "a", line: 5 };
  const { slidingMockThreadClient, slidLocation } = generateOffsetThreadClient(2, location);
  const { dispatch, getState } = createStore(slidingMockThreadClient);
  ... // and so on
 }

naming needs to be improved. it might make sense to make location an array, but i think its getting ahead of ourselves

};
}

function slideMockBp(bp) {
Copy link
Contributor

Choose a reason for hiding this comment

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

same comment here as above on line 79 in breakpoints.js --- probably we can do this in a future pr, where we create a breakpoints utils


break;
const newState = setCondition(state, action);
setPendingBreakpoints(newState);
Copy link
Contributor

Choose a reason for hiding this comment

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

great!

const pendingId = makePendingLocationId(action.breakpoint.location);
let updatedState = undefined;

if (action.disabled) {
Copy link
Contributor

Choose a reason for hiding this comment

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

since these two cases are so different, perhaps they can be functions that return updatedState? then we won't need to do the weird let


const locationId = makeLocationId(breakpoint.location);
const movedLocationId = makeLocationId(actualLocation);
state = state.deleteIn(["breakpoints", locationId]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Personal comment: Its not wrong, I just cringe if I see state being reassigned :P

function filterByNotLoading(bp: any): boolean {
return !bp.loading;
function setPendingBreakpoints(state) {
prefs.pendingBreakpoints = state.pendingBreakpoints;
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

}

function restorePendingBreakpoints() {
return prefs.pendingBreakpoints;
return I.Map(prefs.pendingBreakpoints);
Copy link
Contributor

Choose a reason for hiding this comment

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

👍👍👍👍👍👍

@codecov
Copy link

codecov bot commented May 15, 2017

Codecov Report

Merging #2877 into master will increase coverage by 1.36%.
The diff coverage is 95.4%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #2877      +/-   ##
=========================================
+ Coverage   58.63%     60%   +1.36%     
=========================================
  Files          63      63              
  Lines        2403    2430      +27     
  Branches      493     496       +3     
=========================================
+ Hits         1409    1458      +49     
+ Misses        994     972      -22
Impacted Files Coverage Δ
src/client/firefox/commands.js 18.55% <ø> (ø) ⬆️
src/test/tests-setup.js 100% <ø> (ø) ⬆️
src/actions/breakpoints.js 85.96% <100%> (+1.75%) ⬆️
src/actions/sources.js 48.36% <92%> (+10.52%) ⬆️
src/reducers/breakpoints.js 89.25% <96.72%> (+10.46%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff6f311...a1609f3. Read the comment docs.

@codehag codehag changed the title [WIP] Refactor Pending Breakpoints to fix reloading Refactor Pending Breakpoints to fix reloading May 15, 2017
Copy link
Contributor

@codehag codehag left a comment

Choose a reason for hiding this comment

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

LGTM

@jasonLaster jasonLaster merged commit ea8b5f3 into firefox-devtools:master May 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants