The discrepancy between the data and filled in bubbles seems to be a rendering issue that goes back to the tug-of-war I've been working through between getting the 'delete rank' use case and rendering the initial ranks working at the same time. When I remove isInitialRender, the bubbles are filled, but then deleting ranks doesn't work again.

I've been trying for some time to figure if I can position the isInitialRender toggle or add a condition so both work simultaneously, but so far, one breaks when the other is fixed.

I think I went this route because with both ways I tried to clear the ranks with before, the render issue remained. I slightly modified the logic so instead of checking for the initial render, it checks for the one immediately after the 'Clear' button is clicked to make a temporary exception, and the final test case seems to pass now.

@justin-b-yee following up from the call today, If I remove the clearRanksBlocked stuff it works fine in rank-points. The problem in in some of the cases of rank-step. Also, In rank step, after I clear, and look at what's in the context (when you scroll down in storybook) the category's after a clear aren't set. The should be. I suspect there is a problem in handleOnDone of RankStep not getting delta, or at least not upserting the changes. Or not getting the onDone's..

I suspect there is a problem in handleOnDone of RankStep not getting delta, or at least not upserting the changes. Or not getting the onDone's..

Yeah I think you're right - I did some more testing and when I commented out the onDone line, the ranks didn't reappear after clearing (though of course, they didn't get upserted either). I went back to the previous attempt and called handleRankPoint on all points to clear them. I am seeing the delta with category: '' reach the onDone function, but I also see another call right after that seems to re-write in the last value, which would explain the brief flicker. I'm still trying to figure out where and why this other call is happening though.

@justin-b-yee I made a change to your change to app/components/ranking.jsx so that it would not send onDone if initally empty. I think it will still work for you but let me know. It's merged into master now.

@justin-b-yee I made a change to your change to app/components/ranking.jsx so that it would not send onDone if initally empty. I think it will still work for you but let me know. It's merged into master now.

Thanks! Not only does it still work - the change partially fixed the flicker problem after resolving conflicts. It's now just a problem where only one point is cleared each time the Clear All button is clicked that I can hopefully investigate further.

I wonder - does this happen because we can only upsert one rank at a time, so the clear operation isn't atomic and causes a race condition? I was thinking before that the ranks could be rerendered on data where one is changed to empty and the rest are the previous values, and the data coming back down overwrites the immediate local changes where all are cleared.

• rankByParentId categories cleared via setState, triggers rerender
• Default value of first ranking is '', change triggers onDone. (other rankings trigger their own onDone as well)
• Concurrently, those onDones runs handleRankPoint which upserts the single rank.
• Rank with category: '' is upserted into context, but the rest of the categories in that scope are the previous values.
• Context change triggers rerender, overwrites the emptied rankByParentId to the rankByParentId where all categories are still there except the first.

Yes! You bring up a good point. Up until Friday night, the upsert into the context would create a clone, so all the refs to all the rank objects would be new, causing react to see it as change through the react chain.

With the change I pushed Friday night, upsert was redone so that only the changed objects, and their parent refs are changed. See app/lib/set-or-delete-by-mutate-path.js and it's test. And I'm gong to be talking about this on Monday in the dev meeting. But happy to talk about it and dig into this at a time that works for you.

Within the deriver, it needs to make sure it's not changing the ref of ranks that aren't changed.

Another possibility I'm thinking about, is whether the category going down to Ranking and coming back up are both the same - meaning ''. Or, could one be undefined and something else be doing ''.

There is a case where Rank could get called with each context change, with only one rank changed. But the Rank component shouldn't pass new props to any of it's children. It should see that the new rank coming down is the same as the current rank and stop

But it's also the case that React bunches up state changes that are triggered by the same event, and there may be several or all between retenders.

So inside the useEffect on chanaged to rankByParentId, it should ignore ranks if oldRank===newRank.

Does this make any sense, and does it help? Let me know. And happy to have a call and talk through it.

This is the really deep stuff about how React works, and what we are trying to do to make bidirection data updats work within React.

Thanks for your perseverance!

And it's more complicated than that. I think the lesson is that Rank is keeping state in the middle, but this system is designed for changes to come from the bottom/user or top / data base. But clear is changing the state in the middle first.

One solution might be for clear create it's own delta's and onDone() the changes up, so that they come back down to change the it's state and then rerender the ranking

But this won't work for the Rank story by itself, it need the RankStep and context. But maybe that's okay for now.

Hm, I managed to get two tests to pass, but I'm a bit confused by the behavior I've observed in the last one with my current understanding. Seems like the rank category is not being updated because local.preRankByParentId already has the new values when the deriver is called again, and the conditional checking for changes is false:

 data.preRankByParentId[1].rank = { _id: '4', category: 'neutral', parentId: '1', stage: 'pre' }
 const newPointRankGroupList = derivePointRankGroupList(data).pointRankGroupList 

 LOCAL DATA {
        '1': { _id: '4', category: 'neutral', parentId: '1', stage: 'pre' },
        '2': { _id: '5', category: 'neutral', parentId: '2', stage: 'pre' },
        '3': { _id: '6', category: 'least', parentId: '3', stage: 'pre' }
      }

So rankPointsById[point._id] doesn't get set to the new rank which should be neutral.

         "rank": Object {
            "_id": "4",
    -       "category": "neutral",
    +       "category": "most",
            "parentId": "1",
            "stage": "pre",
          },
        },

I haven't yet found where local.preRankByParentId would get updated with { _id: '4', category: 'neutral', parentId: '1', stage: 'pre' } before this call though, as I'd thought it could only get updated here:

  if (local.preRankByParentId !== preRankByParentId) {
    for (const rank of Object.values(preRankByParentId)) {
      if (rankPointsById[rank.parentId]) {
        if (rankPointsById[rank.parentId].rank !== rank) {
          rankPointsById[rank.parentId] = { rank: rank, ...rankPointsById[rank.parentId] }
          updated = true
        }
      }
    }

    local.preRankByParentId = preRankByParentId
  }

See changes here d7703e6
The tricky part was that in the deriver, after local.preRankByParentId is set to data.preRankByParentId, if the test then changes data.preRankByParentId[1], it's being changed in local too.

Also, did you know you can do: npm run dbtest app/components/steps/__tests__/rank.js