Hardcoded attributeNamePrefix value in xmlParserOptions

[Łukasz Wójcik]

Hi!

First and foremost, thanks for your work!

I've been using the library in my GitHub action and I tried to change attributeNamePrefix property in xmlParserOptions but it didn't work. I had a look at the code and noticed it's hardcoded and thus impossible to change:

feed-extractor/src/utils/xmlparser.js

Line 23 in 4bdcdb1

 attributeNamePrefix: '@_', 

Is there any reasoning behind this decision I'm not aware of? Is it possible to make it modifiable via xmlParserOptions like the rest of the properties?

I can provide a pull request for this if you don't mind.

Thanks a lot!

[Dong Nguyen]

@lwojcik nice to see your feedback.

This fixed setting is just to simplify the normalization process, where we can access the attributes without caring prefix.

feed-extractor/src/utils/normalizer.js

Lines 77 to 97 in 4bdcdb1

 export const getEnclosure = (val) => { 
   const url = hasProperty(val, '@_url') ? val['@_url'] : '' 
   const type = hasProperty(val, '@_type') ? val['@_type'] : '' 
   const length = Number(hasProperty(val, '@_length') ? val['@_length'] : 0) 
   return !url || !type 
     ? null 
     : { 
       url, 
       type, 
       length, 
     } 
 } 
  
 const getCategory = (v) => { 
   return isObject(v) 
     ? { 
       text: getText(v), 
       domain: v['@_domain'], 
     } 
     : v 
 } 

I'm not sure in which case you have to change that setting?

[Łukasz Wójcik]

Thanks for explaining!

In my use case I'd like to explore the possibility of passing an empty string as prefix or replacing it with a different string so that I can expose this feature to the end user in a safe way without resorting to dedicated helpers for specific properties.

If you're against refactoring the helper module, that's fine - but I feel the documentation could do a better job at informing me attributeNamePrefix can't be modified in xmlParserOptions. TypeScript typing doesn't do that either as the type any is passed for xmlParserOptions property.

[Dong Nguyen]

@lwojcik you made me reconsider this issue. Since the library supports some customizations like getExtraFeedFields and getExtraEntryFields, it makes sense to allow any settings of xmlParserOptions to be changeable.