feat(store): add field index to Store_SpliceDynamicData event

[yonadaaa]

Fixes #2222

[changeset-bot]

🦋 Changeset detected

Latest commit: 81be743

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 30 packages

Name	Type
@latticexyz/store	Major
@latticexyz/store-sync	Major
@latticexyz/cli	Major
@latticexyz/dev-tools	Major
@latticexyz/react	Major
@latticexyz/store-indexer	Major
@latticexyz/world-modules	Major
@latticexyz/world	Major
@latticexyz/abi-ts	Major
@latticexyz/block-logs-stream	Major
@latticexyz/common	Major
@latticexyz/config	Major
create-mud	Major
@latticexyz/ecs-browser	Major
@latticexyz/faucet	Major
@latticexyz/gas-report	Major
@latticexyz/network	Major
@latticexyz/noise	Major
@latticexyz/phaserx	Major
@latticexyz/protocol-parser	Major
@latticexyz/recs	Major
@latticexyz/schema-type	Major
@latticexyz/services	Major
@latticexyz/solecs	Major
solhint-config-mud	Major
solhint-plugin-mud	Major
@latticexyz/std-client	Major
@latticexyz/std-contracts	Major
@latticexyz/store-cache	Major
@latticexyz/utils	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[holic]

Seeing this all laid out, I am wondering:

• Do we still like the Store_SpliceDynamicData name since splice events are now ~guaranteed to operate on one field at a time and it includes both information for splicing within the field and for all of the dynamic data? Wondering if this should be something like Store_SpliceDynamicField to clarify the intent.
• With above, I am also wondering if it's worth clarifying some argument names like startWithinField to fieldStart and start -> dynamicDataStart.
• "dynamic" in dynamicFieldIndex might be redundant since this is a Store_SpliceDynamicData event. Also worth clarifying if this is the field index in the list of fields for the whole schema or field index among dynamic fields (I think it's the former?)

[alvrs]

Do we need startWithinField? Couldn't that be computed from dynamicFieldIndex, start and encodedLengths? I'd prefer adding that one additional field to the event than refactoring the event name and other field names. The current naming feels very intuitive if you're thinking of the data as one byte blob, while the Store_SpliceDynamicField naming would be a little more intuitive if you're storing data in separate locations, but I don't there is a strong enough bias in either direction to change the name at this point.

[holic]

const fieldLengths = getFieldLengths(encodedLengths); // some sort of decoding function
const fieldStart = fieldLengths.slice(0, dynamicFieldIndex).reduce((sum, length) => sum + length, 0);
const startWithinField = start - fieldStart;

checks out ✅