Closed Jordaneisenburger closed 3 years ago
created in Jira backlog for grooming/prioritization
Just to add to what @Jordaneisenburger said, it currently feels odd that queries are purposefully kept out of peregrine but then the talon is gatekeeping the information that flows back to the provider of the query.
Currently it's providing the illusion that one can easily just adapt the query which is not the case.
This is linked to https://jira.corp.magento.com/browse/PWA-497, which is currently in our backlog.
The desire for raw data is clear here, but we do need to consider that some talons call multiple queries/mutations. One way we could handle this might be an array or map of queryname: data
, sort of like we do here for errors.
Is your feature request related to a problem? Please describe. In many cases the category pages will be customized to fit the customers needs. Let's say we've added an arbitrary attribute like 'category_awesome_attr' to the category query. If we would like to show that on the frontend. We need to overwrite the whole talon, just to display one extra value.
Doing this would decrease upgradability and be more prone for future errors. Besides that it would very redundant.
Describe the solution you'd like In many cases talons flatten the data returned in the talonProps. This feels like a good practice but it would make it much more extensible if talons also always optionally return the raw query data. This way the implementing party always have their data and we would make it their responsibility to handle it.
Describe alternatives you've considered Another solution would be to optionally supply the talon with a customMapper that would deep merge a (yet to implement) default mapper. This would require more work but in the long term be more viable since you could rewrite
categoryName
with custom data.Please let us know what packages this feature is in regards to:
venia-concept
venia-ui
pwa-buildpack
peregrine
pwa-devdocs
upward-js
upward-spec
create-pwa