Behavior of parse_filter vs. render_filter correct?

[skorth]

Hey,

i know my second issue in two days and i still need to answer the first one. But currently i just have issues that i didn't understand.

Within the docs http://trailblazer.to/gems/representable/3.0/function-api.html#parse-filter there are two examples that i try to use:

property :id, parse_filter: ->(fragment, options) { fragment.strip } and
property :id, render_filter: ->(input, options) { input.strip }

The confusing thing is, that the tests https://github.com/apotonick/representable/blob/master/test/coercion_test.rb#L43-L44 are using different Attributes. The parse_filter uses the input and render_filteruses the fragment Attribute. When i use it like this...

property :something,
  reader: ->(represented:, doc:, **) { ... },
  parse_filter: ->( options ){ 'foo' },
  setter: ->(options) { ..... }

...the setter options[:fragment] is still the original value but the setter options[:input] gets (set to 'foo') filtered. As I understand the docs the input should only be set within the render and not the parsing process, or?

[apotonick]

From your code I can see that you're overusing the Representer layer. Keep in mind, this is not a data mapper (evidenced by your use of setter and reader and all that), and also not a coercer. Have a look at the Trailblazer architecture, all the setter/coercion/parse_filter things happen on the twin.

I know this doesn't really help you just now, but I can't remember exactly why Representable works the way it works.

[skorth]

@apotonick Thanks for you feedback. I refactored my code into representable and twins. Your are right, it makes more sense to handle the mapping/coercion within the twin. Thanks!