The components SearchBar and AutocompleteSearchBar require to update their local state from the redux store when queryString gets updated. In order to achieve that, as it is suggested from react documentation fully-uncontrolled-component-with-a-key we have introduced a key on each of the components. This will force the component to get recreated every time the queryString changes.
Steps to Reproduce
The problem occurs when we override the aforementioned components. For the override mechanism, for each component we provide an element that can get overridden. Another option we have is to replace the complete component instead of its inner element. Consider something like the following.
While in this case we have to provide explicitly in our implementation the key <FooSearchBar key={queryString} > because its get swapped out, and prevents the component to reconstruct and so fetch the latest redux state.
Additional context (options)
If we keep the existing behaviour, it should be clearly documented in RSK docs.
Because we are interested only in the queryString prop it might worth looking into the more cumbersome but still straight forward solution of getting derived props, which is also suggested as an alternative from react documentation.
Use third part libraries to subscribe to redux state changes.
Where are you standing guys on this? @mvidalgarcia, @zzacharo, @ntarocco?
Package version: v1.0.0-alpha.3
Describe the bug
The components
SearchBar
andAutocompleteSearchBar
require to update their local state from the redux store whenqueryString
gets updated. In order to achieve that, as it is suggested from react documentation fully-uncontrolled-component-with-a-key we have introduced akey
on each of the components. This will force the component to get recreated every time thequeryString
changes.Steps to Reproduce
The problem occurs when we override the aforementioned components. For the override mechanism, for each component we provide an
element
that can get overridden. Another option we have is to replace the complete component instead of its inner element. Consider something like the following.In this case everything will work as expected.
While in this case we have to provide explicitly in our implementation the key
<FooSearchBar key={queryString} >
because its get swapped out, and prevents the component to reconstruct and so fetch the latest redux state.Additional context (options)
queryString
prop it might worth looking into the more cumbersome but still straight forward solution of getting derived props, which is also suggested as an alternative from react documentation.Where are you standing guys on this? @mvidalgarcia, @zzacharo, @ntarocco?