separate out vendor component calls #10430
Conversation
src/app/vendors/actions.ts
Outdated
| const defs = manifestSelector(getState()); | ||
| if ( | ||
| // we're done if this is d1. or if defs aren't loaded? | ||
| // can this kick off before defs are loaded?? what if it does??? |
There was a problem hiding this comment.
You might be able to put this in a store observable, so that it will kick off after defs are loaded?
There was a problem hiding this comment.
I think it always kicks off after defs are loaded.
There was a problem hiding this comment.
great to be reassured of, definitely appeared to that way in all testing
src/app/inventory/store/sockets.ts
Outdated
| // a nice long instanceId is a real one and "should" have this data | ||
| // (short is actually a vendor item index. we'll let that build from defs.) | ||
| item.itemInstanceId.length > 14 && |
There was a problem hiding this comment.
The heuristic makes me uncomfortable, but I'm not sure of a better one.
There was a problem hiding this comment.
the conversion for vendor items, from just a number(as a string) to ${vendorHash}-${saleIndex} happens later in item build unfortunately, or it would be more identifiable
item ids start at 69 sextillion, 19 digits, even in d1, and count up, so this is not likely to fail any time soon
src/app/vendors/reducer.ts
Outdated
| const newItemComponents = vendorResponse.itemComponents; // big combined set, keyed by vendor hash | ||
| const existingItemComponents = oldVendorsResponse?.itemComponents; // set for a single vendor |
There was a problem hiding this comment.
yeah! unsure when that swapped. combination went through several iterations. thank you
src/app/vendors/reducer.ts
Outdated
| return { | ||
| ...state, | ||
| vendorsByCharacter: { | ||
| ...vendorsByCharacter, | ||
| [characterId]: { | ||
| vendorsResponse: { ...oldVendorsResponse, itemComponents }, | ||
| lastLoaded: Date.now(), | ||
| error: undefined, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
This is all perfectly reasonable, though the immer version might read better:
| return { | |
| ...state, | |
| vendorsByCharacter: { | |
| ...vendorsByCharacter, | |
| [characterId]: { | |
| vendorsResponse: { ...oldVendorsResponse, itemComponents }, | |
| lastLoaded: Date.now(), | |
| error: undefined, | |
| }, | |
| }, | |
| return produce(state, (draft) => { | |
| draft.vendorsByCharacter[characterId].vendorsResponse.itemComponents[vendorHash] = vendorResponse.itemComponents; | |
| draft.vendorsByCharacter[characterId].lastLoaded = Date.now(); | |
| }), |
src/app/vendors/actions.ts
Outdated
| const defs = manifestSelector(getState()); | ||
| if ( | ||
| // we're done if this is d1. or if defs aren't loaded? | ||
| // can this kick off before defs are loaded?? what if it does??? |
There was a problem hiding this comment.
I think it always kicks off after defs are loaded.
| // deprioritize vendors whose sections are collapsed on the vendors page | ||
| compareBy((h) => Boolean(collapsedSections[`d2vendor-${h}`])), |
src/app/vendors/actions.ts
Outdated
| for (const vendorHash of vendorsNeedingComponents) { | ||
| start = Date.now(); | ||
| const vendorResponse = await getVendorSaleComponents(account, characterId, vendorHash); | ||
| timings.componentsTime += Date.now() - start; | ||
| timings.componentsFetched++; | ||
| dispatch(loadedSingle({ vendorResponse, characterId, vendorHash })); | ||
| } |
There was a problem hiding this comment.
This could be parallelized in batches, but this is a perfectly fine start.
| return ( | ||
| item && | ||
| // probably just need this for weapon perks and armor stats? | ||
| // TO-DO: what about bounties and quests? where's their pre-existing progress stored? do we care? |
There was a problem hiding this comment.
It might affect whether bounties appear purchase-able?
There was a problem hiding this comment.
bounties appear correct in my testing
addresses #10426 (Bungie-net/api#1887)
early sanity-checking welcome please. is this a good way to combine these?
it results in a pleasant filling-in of info, and polaroids gradually appearing on the vendors page,
but as noted in loadAllVendors comments, there are other possible strategies
this serially fetches, but that ends up taking like 50 seconds for 9 vendors.
should we ratelimit, and dispatch them all, and await allResolved? what rate?