User state lost in packState/unpackState

[devonray]

It's clear that router.result contains only custom data specified in the routes hash, but it's not clear how to dynamically persist custom data to history.

My specific use case revolves around storing scroll state in the history entry in order to support browser back/forward navigation while preserving scroll position for paginated lists. In v13 both packState and unpackState utils support the state attribute, but it seems like it's getting stripped on the locationDidChange action at https://github.com/FormidableLabs/redux-little-router/blob/v13.0.0-0/src/enhancer.js#L36, perhaps due to the absence of state from the Location type definition.

Given that state seems to be supported throughout much of the code base I presume this was an unintentional omission from the resulting location descriptor, but I wanted to ask for clarification.

[tptee]

Hey @devonray, this definitely looks like a regression! I'll ping you with a new alpha that fixes this.

[devonray]

Upon further inspection I realize I may have misrepresented the root problem. There seem to be two orthogonal problems that led to my confusion and initial inquiry:

1. When updating router.state the new state is not immediately reflected in the store. Repro steps:
   a. navigate: push(urlA)
   b. update scroll state: replace({}, { state: { scroll: {...} } })
   c. router.state == {} // expected router.state == { scroll: {...} }
   d. navigate: push(urlB)
   e. router.state == {}
   f. navigate back: back()
   g. router.state == { scrollState: {...} } // Note now the state is available
2. When updating router.state the new state is destructively replaced. Repro steps (assuming the first issue above is fixed so we can immediately inspect state):
   a. persist some state: replace({}, { state: { someState } })
   b. router.state == { someState }
   c. persist some other state: replace({}, { state: { someOtherState } })
   d. router.state == { someOtherState } // expected router.state == { someState, someOtherState }

I could see a case for the second issue working as designed. The first issue, however, seems like a bug.

[codeincontext]

Did you find a solution to this? We're trying to store a scroll position with each item in the history

[tptee]

Should be fixed in v14.0.0-1! Give me a shout if you still run into issues.