Already implemented in our fork but could be useful / better implemented :)

[DanielShuey]

Hey Nick,

Just letting you know about some features that I've implemented (in a really really ugly way :P), due to time constraints I haven't had a lot of time to look at the code and needed it done asap. I will fix the code up later when I have time and possibly pull-request.

Basically we are trying to use Representable to populate our models by passing in an extremely large and complex JSON/XML document that I cannot mention due to privacy reasons. Just think Enterprise + Legacy scale :P.

Please find some time to look at our fork (Locomote).

After you've vented about how bad my code is :P, hopefully you can think of much better ways of implementing features that cater to the same requirements if that is in your interest. :)

---

1. Post-processing after hook and :eval parameter

Due to the complex nature of the document we are passing in, we needed a way to build relationships up between objects post-process.

The current params like parse-strategy, required too much boilerplate for what we wanted to do, we needed something more simple and needed to use it for almost half the properties.

The after hook is a method->block that is called as a last resort for linking objects together and doing post-processing on an object.

Example:

class LibraryRepresenter
    after do
        users.each do |user|
          user.books = books.select { |book| book.user_id == user.id }
        end
    end

    collection :books do
        property :user_id
    end

    collection :users do
        property :id
    end
end

The eval hook is done specifically in context of the property, also post-process.

collection :users
    collection :books, eval: -> { books.select { |book| book.user_id == user.id } }
end

Better example and reasoning is shown in the next section.

---

2. parent attribute

Child collections and properties can access the parent representer object during post-process. Again this is due to the "spidery" nature of the documents we receive, we need to re-arrange everything into something that actually looks organised.

We literally get documents where should-be nested objects are instead in a what-is-this-i-don't-even random location. Not only this, but we have to access these objects in order to link other randomly placed objects together.

I shit you not this is what its like (replace theme with what we are actually dealing with)

class LibraryRepresenter

    collection :book_names
        property :name
        property :book_ref
    end

    # Why this wrapping appears I don't know
    nested :book_data

      #The actual books collection for model because most of the stuff lies here and is most reliable
      collection :books, as: :book_segment do
        property :book_number
        property :key, eval: -> { book_number[3..-1] }
        property :name, eval: -> { parent.book_names.detect { |bn| bn.book_ref == ref } }
        collection :infos, eval: -> { parent.infos.select {|info| info.segment_ref == ref} }
        property :pricing, eval: -> { parent.pricings.detect { |p| p.key == infos.book_pricing_ref } }
        property :issue_dates, eval: -> { infos.map {|info| info.try(:issue_date) } }
        # + lots of other stuff we desperately need
      end
      collection :pricings, as: :book_pricing do 
        property :base_price
        property :key
      end
    end

    # This links pricings to book, sometimes they don't always appear so we can't use this for the main collection.
    collection :infos, as: :book_info do
        property :book_pricing_ref
        property :book_segment_ref
        # Sometimes doesn't appear so we have to conditionally set this
        property :issue_date
        property :you_get_the_idea
    end
end

Multiply this x10 and now you know why the current features require too much boilerplate for what we want to do. :P

---

3. Default class

We didn't want to have to declare class: OpenStruct for every... single... collection for which we have about 20 or so and possibly more in the future. Setting a default class in the Config would be nice.

Example:

collection :libaries

Is the same as

collection :libaries, class: OpenStruct

---

4. Magic Class instantiation

For the same reason as above, we have lots of collections. We have Representable automagically find which Representable it belongs to. Kind of like how some Ruby database gems do it.

Example:

collection :libraries

Is the same as

collection :libaries, extends: LibraryRepresenter

This behaviour however does not happen if the collection is inlined as a matter of design.

---

5. Type-cast on parse (symbol or class constant)

We want to be able to use symbols because of the auto-load nature of rails but also we wanted the type casting to happen immediately and not during render.

Example:

property :book_name, type: BookName

property :book_name, type: :book_name

book = OpenStruct.extend(BookRepresenter).from_json({book_name: 'A Song of Ice and Fire'}.to_json)

book.book_name.class
$ => BookName

---

6. Always return [] and force conversion to array for collections

Due to the inconsistent nature of the documents we are receiving we needed collections to always return [] if the fragment doesn't exist and always be parsed/set as an array, no matter what even if it is sent in as a singular (even in JSON).

Single items are wrapped in [] before being parsed if Representable knows it should be a collection.

---

7. :set parameter

During parsing we needed some properties to trigger the evaluation of another property without it getting set itself. Saves use from using try or conditional statements everywhere.

Either that or the combination of some sort of :ignore parameter and :eval.

---

In the works

1. :ignore or :persist parameter

An :ignore parameter to capture but not ultimately set or persist the property in the model is in the works.

---

2. Depluralize collection names to find fragment

When finding fragment and no :as specified, try finding using non-pluralized name, and if the fragment is not found, try again using pluralized name.

This is to get around all the boilerplate revolving things like

collection :books, as: :book

---

3. Nested collections need to be set default

As said in other posted issue

---

Obviously up to you how you decide to go about these. These are features that we are currently using so if you got better ideas or advice on how to implement them that would be good too.

Looking forward to your reply

Cheers

[apotonick]

https://twitter.com/apotonick/status/501196534759706625 😄

[fredwu]

👏

[johncarney]

👍 Might be useful to split this into separate issues.

[apotonick]

Yeah, that is awesome, let's go through it, discuss it here and then split out issues.