Modeling "black box" data

[markaddleman]

(from #65 (reply in thread))

Within my application, I have two objects which the UI should treat the same. As far as the UI is concerned, there are only two relevant attributes, a friendly name and an id. The id contains information which is "black boxed" to the UI. The server uses the ID info to identify which particular object it is.

For example, I an object which represents a physical object in the real world. From the UI's point of view, the object looks like this:

{:object/friendlyName "Doorbell"
  :object/id {:object/type :physical
                   :physical.object/customer-id 123
                   :physical.object/device-id 456
                  }
}```

Likewise, there is a virtual object which is computed by rules.  The from the UI's point of view, the object looks like this:
```clojure
{:object/friendlyName "Antique turn lightswitch"
  :object/id {:object/type :virtual
                   :virtual.object/rule-definition-id 789
                  }
}```

The point of the `:object/id` attribute is to simplify and abstract the server-side data model for the UI.  The user operates on one of the objects, the UI simply needs to supply the server with the data in the ID - whatever that data happens to be.

For server-side convenience, I have a couple of resolvers that package ids for the UI:
```clojure
(pco/defresolver physical-id [{:physical.object/keys [customer-id device-id] :as id}]
  {:object/id (assoc id :object/type :physical)}
)

(pco/defresolver virtual-id [{:virtual.object/keys [rule-definition-id] :as id}]
  {:object/id (assoc id :object/type :virtual)}
)

While I have some questions around Pathom and query planning, @wilkerlucio brought up a question of whether I'm taking a good approach to modeling the data. Any thoughts on this approach?

[wilkerlucio]

Looking just at this small example I wonder why to wrap the id data under :object/id?

You could keep it flat, and infer the type at the same level, using the available data, like:

(pco/defresolver object-type 
  [{:keys [physical.object/customer-id
           physical.object/device-id
           virtual.object/rule-definition-id]}]
  {::pco/input
   [(pco/? :physical.object/customer-id)
    (pco/? :physical.object/device-id)
    (pco/? :virtual.object/rule-definition-id)]}
  {:object/type
   (cond 
     (and customer-id device-id)
     :physical
     
     rule-definition-id
     :virtual)})

In general, is better to keep things flat as possible.

As an experience point, we had around trying to use generic ID's in Fulcro applications. They tend to not scale very well because they don't help to narrow the possibilities of the data to navigate. In contrast with more specific ids, that can go straight to the point (instead of having to try N possibilities because the current data isn't specific enough).

[markaddleman]

This is not a Fulcro app, unfortunately.

Ultimately, the problem I'm trying to solve is a separation between the UI and server. The user manipulates an object, the UI must send some identifying data to the server. Without packaging the identifying data in a well-known attribute (eg, object/id), how would the UI know the right attributes to send? Naively, it seems like the only alternative is that the UI understands the server's internal data model.