Vuex Store not "shared" with component SearchFilter

[luipir]

For some reason most of values in Vuex store are not shared with component SearchFilter used by router Search.
My goal is to get high level collection BBOX to show it as zoom of the spatial filter.
But "catalogs" getter return null or empty array.

Note that getter "catalogs" eturn empty array also int he upper level Search.vue

[m-mohr]

SearchFilter is a Vue component and is used in various places, thus the relevant state is shared through props, not through the VueX store. The components that use the SearchFilter can get the state from VueX and pass it to the SearchFilter.

I can't give more details on your issue as the description is very vague and has no example attached.

[luipir]

I can't reopen the issue, but these are my contribution to the discussion:

1. code is almost as the ol-stack branch and a version is here:
   https://github.com/luipir/stac-browser/commits/ol-stac-enhanced
2. run on this preprod catalog, btw any catalog is ok:
   npm start -- --catalogUrl="https://geoportale-preprod.comune.roma.it/stacapi/" --port=8085
3. SearchFilter.vue is used by Search.vue and also there the store is not shared e.g. breacking exectution here:
   https://github.com/luipir/stac-browser/blob/ol-stac-enhanced/src/views/Search.vue#L223
   give [] as this.$store.getters.catalogs so it is hard to pass it to sub component SearchFilter if binding would pass an empty array.

[m-mohr]

By the way, any component can access this.$store. If something is not available at the time yet you are using it, it may just be accessed too early (created us usually too early as the HTTP data requests are not finished yet, same applies often to mounted, too). The line you are referring to has nothing to do with the store, so I don't understand what is breaking. You need to implement it in a reactive way, so watch changes of a property and only react on it whenever it's changing.

[luipir]

By the way, any component can access this.$store. If something is not available at the time yet you are using it, it may just be accessed too early (created us usually too early as the HTTP data requests are not finished yet, same applies often to mounted, too). The line you are referring to has nothing to do with the store, so I don't understand what is breaking. You need to implement it in a reactive way, so watch changes of a property and only react on it whenever it's changing.

could be too early, I'll check, thx for the hint.
The line I posted is where I added a breakpoint to check the available values in the store

[luipir]

no way! store is accessible but not synched with the Vuex store. @m-mohr are you able to access this.$store.getters.catalogs in Search component?
If I've this.$store.getters.catalogs is an array with 1 element in StacBrowser.vue, in Search component it is an empty array. And if empty there I can't pass it to SearchFilter.
Lost in Store understanding why many are using Pinia as store manager.

[m-mohr]

Makes sense that it's empty. state.data is null for the search page and that's what the catalog getter depends on. state.data conatins the current STAC entity that is shown, but the search page doesn't show a specific STAC entity, thus it's null. store.catalogs is meant to be the catalogs for the current STAC entity. What could potentially help is to use getters.root and then either get cached data rom getChildren or use getters.rootLink and load the children manually.

Pinia didn't exist when STAC Browser was initially implemented, but it's also not the issue here.

[luipir]

lost! I tried to override reading catalogs seting up a static value (the bbox array) in the store commit from Catalog.vue (and visible at StacBrowser.vue level) but not shared at all in Search or SearchFilter.

[m-mohr]

I'm not sure what you are trying to solve. Do you want to extract the bbox from a single collection depending on which collection is chosen in the search filter and use that as a default for the map view in the search filter?

[luipir]

exactly @m-mohr!
for now I passed default BBOX via config because I can't find the way /search route could receive the bbox.

[m-mohr]

That sounds like a reasonsable feature request for STAC Browser, maybe write a feature request in this issue tracker for it if there's none. May take a while to implement generally though.

[luipir]

I would have implemented it and prepared a PR, but was harder that expected :/ in the meantime I've already a PR #587 to have a configurable default extent to zoom in in the spatial search.

[m-mohr]

Please open an issue regardless of whether you implement it or no so that we don't forget it.
I don't have the time right now to review PRs, but will hopefully get to it sometime in May.

[luipir]

added the feature request: #592

[luipir]

I would have implemented it and prepared a PR, but was harder that expected :/ in the meantime I've already a PR #587 to have a configurable default extent to zoom in in the spatial search.

added also the feature request #591 for the PR #587