fix: filter with special characters

[MoritzRS]

PR Type

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] CI-related changes
[ ] Documentation content changes
[ ] Application / infrastructure changes
[ ] Other:

What Is the Current Behavior?

When applying search filter with characters like "&" or "/" leads to false encodet parameters in the rest request.

What Is the New Behavior?

When applying search filter with special characters, parameters are encodet properly.

Does this PR Introduce a Breaking Change?

[ ] Yes
[x] No

Other Information

The change from decodeURI to decodeURIComponent works for the filters, but wasn't tested enough and might lead to unexpected behavior elsewhere.

[dhhyi]

@MoritzRS Following https://stackoverflow.com/a/747700 using decodeURIComponent instead of decodeURI should be exactly what is originally intended, since we are working inside the query param boundary on a specific param. (I learned something today 😅). Thanks for the PR.

But I wonder: Normally, Angular should take care of encoding and decoding the params properly, so why do we have to do it here at all? I suspect there is a wrong encodeURI somewhere that causes it.

[MoritzRS]

I also found this suspicious that you have to decode at all. I will look into this and see if I find that encoding part. Thanks for replying

[MoritzRS]

The request at https://pwa-ish-demo.test.intershop.com/INTERSHOP/rest/WFS/inSPIRED-inTRONICS-Site/rest;loc=en_US;cur=USD/productfilters?searchTerm=* already returns the encoded string. So "/" is already encoded as "%2F" when angular receives the possible filter options

[dhhyi]

@MoritzRS That means, we just have to decoreURLComponent correctly when we parse the filter values.

If I follow the mapping, it happens here:

intershop-pwa/src/app/core/models/filter-navigation/filter-navigation.mapper.ts

Line 60 in 9324733

...stringToFormParams(facet.link.uri.split('?')[1] || ''),

So if we look at this line in the stringToFormParams:

intershop-pwa/src/app/core/utils/url-form-params.ts

Line 35 in 9324733

return { key, value: values.split(separator) };

The decoding can happen with values.split(separator).map(decodeURIComponent).
And then we would not need the decoding in appendFormParamsToHttpParams at all.

Does that sound plausible?

[MoritzRS]

Seems good to me and works just as expected. Thanks 😄

[MoritzRS]

Worked for the brand filter only but breaks every other Filter. First commit worked for me with all other filters but I'll do some tests before reverting.

[dhhyi]

@MoritzRS No, please don't revert, we only go forward! 😄

As far as I can see, it only doesn't work for prices, because they use range instructions and also have encoded keys, so they also must be decoded and the line should become:

{ key: decodeURIComponent(key), value: values.split(separator).map(decodeURIComponent) }

[MoritzRS]

Should work by now. Thanks for your help 😄

I'll do my best to verify changes are working before committing in the future so we don't always have this back and forth over such little changes 😅

[dhhyi]

I'll do my best to verify changes are working before committing in the future so we don't always have this back and forth over such little changes 😅

No worries, that's what these collaboration tools are built for. It just takes a little bit longer 😉👍